There are a number of concepts that are fundamental to the configuration manager subsystem, and indeed, the kernel in general.
Resources
These correspond to mechanisms by which a driver communicates
with a device. There are two sorts:
First-order resources which represent communication mechanisms directly interfacing to low-level hardware, usually implemented by the processor/CPU or by external hardware, such as interrupts, DMA channels, I/O ports and memory address ranges.
Second-order resources which represent communication mechanisms implemented through another driver, such as a low-level SCSI interface driver or the parport driver. This intermediate driver may well deal directly with first-order resources, or may itself deal with second-order resources.
Resources are represented internally be resource tokens. Each token specifies the type of resource and it's currently allocated value. Tokens may also hold more information. For instance, each interrupt tokens provides the address of an interrupt handler to be executed, and tokens allocated to the same interrupt are strung together to provide a list of handlers to be executed when an interrupt is triggered.
Devices
A device is a hardware entity
that typically performs an interaction with the outside world for the
system. Such devices include graphics cards, sound cards,
keyboards, modems and mice.
However, a
device can also perform or govern interactions internal to the
computer, such as a controlling how another device interrupts the
processor. Such devices include bus bridges, PIC's, DMA
controllers, and Processors.
There are two types of device available through the subsystem:
Primary devices which are those that the CPU can access directly. Such devices include USB ports, IDE controllers, and SCSI controllers.
Secondary devices which are those that the CPU has to access indirectly through some intermediary device. Such devices include USB keyboards, IDE disk drives and SCSI CD writers.
A device has a configuration associated with it that consists of a list of resource tokens specifying the resources by which a driver may gain access to the device.
Buses
A bus is a logical collection of
devices that almost certainly reflects some underlying electrical
grouping.
For example, the system could include a "PCI.0" bus in which several devices plugged into the motherboard are multiplexed by means of the PCI electrical protocol and configured by the PCI register access protocol. This same system could also have an "IDE.0" bus which represents the virtual bus hanging off the first port on an IDE controller which involves a pair of IDE disk drives connected to the electrical interface on the motherboard by a piece of ribbon cable.
Buses also follow a hierarchy - one bus gives access to another by means of a bridge device. Using the above example, the IDE controller may be viewed as a bridge that allows access from the PCI.0 bus to the IDE.0 and IDE.1 buses.
Interfaces
An interface represents a
protocol by which a device can be accessed, configured and
controlled, if at all possible. Such interfaces currently include the
commonly known Plug'n'Play and PCI, but could
potentially include others, such as PCMCIA,
IDE bus and SCSI bus.
There is a legacy interface for devices that do not support any sort of configuration protocol.
Drivers
A driver is a kernel object or
(sub-)program that provides a service to the kernel based on the
controlling of a device. Such services frequently include providing
access to real devices as block device files and character device
files.
The manager provides a way of associating logical devices with such driver objects, thereby conferring ownership in a more manageable way. Note, however, that a driver can produce even more logical devices as the result of being associated with a device. For instance, the PCI bridge driver that associates with a bridge to a PCI bus will discover all the devices on the new PCI bus when the association is made and will place these directly back into the manager subsystem.
Drivers can be compiled directly into the boot-time kernel or can be loaded as modules, even demand loaded, at a later date.