* src/sys/sys/bus.h
typedef enum device_state {
DS_NOTPRESENT, /* not probed or probe failed */
DS_ALIVE, /* probe succeeded */
DS_ATTACHED, /* attach method called */
DS_BUSY /* device is open */
} device_state_t;
struct driver {
void *priv; /* driver private data */
# DEFAULT is the method that will be used, if a method was not
# provided via: DEVMETHOD()
METHOD int doit {
device_t dev;
METHOD void doit_to_child {
device_t dev;
driver_t child;
} DEFAULT doit_generic_to_child;
# Foo subsystem/driver (a comment...)
int FOO_DOIT(device_t dev);
int FOO_DOIT_TO_CHILD(device_t dev, device_t child);
*Device States _device_state_t*
*_driver_t_ Implementation*
A `device_state_t` type, which is an enumeration, `device_state`. It contains the possible states of a Newbus device before and after the autoconfiguration process.
A device driver is a software component which provides the interface between the kernel's generic view of a peripheral (e.g., disk, network adapter) and the actual implementation of the peripheral. The _device driver interface (DDI)_ is the defined interface between the kernel and the device driver component.
A device in the Newbus context represents a single hardware entity in the system. For instance each PCI device is represented by a Newbus device. Any device in the system can have children; a device which has children is often called a _"bus"_. Examples of common busses in the system are ISA and PCI, which manage lists of devices attached to ISA and PCI busses respectively.
A source file, "[.filename]#foo_if.c#" is also created to accompany the automatically generated header file; it contains implementations of those functions which look up the location of the relevant functions in the object's method table and call that function.
An ISA device might want to map its IO port at `0x230`, so it asks its parent, in this case the ISA bus. The ISA bus hands it over to the PCI-to-ISA bridge which in its turn asks the PCI bus, which reaches the host-to-PCI bridge and finally the nexus. The beauty of this transition upwards is that there is room to translate the requests. For example, the `0x230` IO port request might become memory-mapped at `0xb0000230` on a MIPS box by the PCI bridge.
As the Newbus API is huge, this section makes some effort at documenting it. More information to come in the next revision of this document.
At the top level resides the _"root"_ device which is the parent to hang all other devices on. For each architecture, there is typically a single child of "root" which has such things as _host-to-PCI bridges_, etc. attached to it. For x86, this "root" device is the _"nexus"_ device. For Alpha, various different models of Alpha have different top-level devices corresponding to the different hardware chipsets, including _lca_, _apecs_, _cia_ and _tsunami_.
Chapter 14. Newbus
Character Devices
Device Drivers