FreeBSD uses a configuration system known as ``new-bus.'' [5] In this system, an opaque ``device_t'' type object represents each bus/device. There are functions to manipulate device_t objects. These functions (e.g. probe, attach, allocate resources) are device specific. They are invoked through a function table that acts as an associative array. The array key is called a method. This is the same technique used in the BSD virtual filesystem layer (VFS). Each device has a parent device, except for the root device. Each device_t object has two device-specific structures: ``ivar'' and ``softc.''
The softc structure is a device-specific structure used to store a device's state. Each driver determines the size of its own softc structure, and the new-bus framework allocates memory for the softc structures as devices are configured.
The ``ivar'' structure is used by a parent device to manage its children. This variable should not be accessed from the child device directly, but via the parent device method. The child device uses this method to obtain bus-specific values and resources. An example of this method is BUS_READ|WRITE_IVAR, which is used to access a bus-specific value. This function is usually wrapped by macro-definition in a bus-specific header file.
PnP devices are processed by a ``pnp'' or ``pnpbios'' driver that provides only the DEVICE_IDENTIFY method. The DEVICE_IDENTIFY method is usually called from a parent bus's routine, after the bus was probed and before the actual attach process, via the bus_generic_probe function. This method records the device's logical id in the ISA bus-specific ivars structure. This value is then used when the isa_get_logicalid macro is invoked. This macro calls the BUS_READ_IVAR bus method to get the ID.
In FreeBSD ACPI, all device objects, thermal zone objects, and some other fixed features are added as child devices in the acpi bus attach code. This is done with the ``device_add_child'' function. Once an ACPI child device is added, this function sets ACPI object handles in the ivars. The probe routine check to see whether the _HID of the device will match the driver. If it does, then the attach routine calls the resource parser to get the resources the driver will use.
The Host-PCI bus bridge appears in the ACPI namespace and is treated as an ACPI-specific device. The driver will call the machine-dependent PCI bridge function to implement a bus-bridge function and manage PCI interrupt routing with ACPI. In ACPI, PCI routing information is in a _PRT object. A _PRT object contains an array of structured objects, each of which has information about the slot, pin, and interrupt source. The interrupt source points to the device object of the interrupt router and assigns the interrupt resource to the device route interrupt to the pin. The interrupt router device object is not currently treated as a FreeBSD new-bus device. The ACPI device driver mimics some ISA-like behaviors. This responds to the isa_get_logicalid function and answers the device logical id value, using _HID object. Figure 4 shows device tree constructed from ACPI name space.
Prior to September 2001 a different approach was taken. The earlier approach was closer to a PnP driver. The ``acpi_isa'' driver was used for this. Like a PnP driver, the ``acpi_isa'' driver provides only the DEVICE_IDENTIFY method.
