One of the more significant changes in the 2.5 development series is the
creation of the integrated device model. The device model was originally
intended to make power management tasks easier through the maintenance of a
representation of the host system's hardware structure. A certain amount
of mission creep has occurred, however, and the device model is now closely
tied into a number of device management tasks - and other kernel functions
The device model presents a bit of a steep learning curve when first
But the underlying concepts are not that hard to understand, and
driver programmers will benefit from a grasp of what's going on.
The fundamental task of the driver model is to maintain a set of internal
data structures which reflect the architecture and state of the underlying
system. Among other things, the driver model tracks:
- Which devices exist in the system, what power state they are in, what
bus they are attached to, and which driver is responsible for them.
- The bus structure of the system; which buses are connected to which
others (i.e. a USB controller can be plugged into a PCI bus), and
which devices each bus can potentially support (along with associated
drivers), and which devices actually exist.
- The device drivers known to the system, which devices they can
support, and which bus type they know about.
- What kinds of devices ("classes") exist, and which real devices
of each class are connected. The driver model can thus answer
questions like "where is the mouse (or mice) on this system?" without
the need to worry about how the mouse might be physically connected.
- And many other things.
Underneath it all, the driver model works by tracking system configuration
changes (hardware and software) and maintaining a complex "web woven by a
spider on drugs" data structure to represent it all.
Some device model terms
The device model brings with it a whole new vocabulary to describe its data
structures. A quick overview of some driver model terms appears below;
much of this stuff will be looked at in detail later on.
- A physical or virtual object which attaches to a (possibly virtual) bus.
- A software entity which may probe for and be bound to devices, and
which can perform certain management functions.
- A device which serves as an attachment point for other devices.
- A particular type of device which can be expected to perform in
certain ways. Classes might include disks, partitions, serial ports,
- A top-level view of the system's structure. Subsystems used in the
kernel include devices (a hierarchical view of all devices
on the system), bus (a bus-oriented view), class
(devices by class), net (the
networking subsystem), and others. The best way to think of a
subsystem, perhaps, is as a particular view into the device model data
structure rather than a physical component of the system. The same
objects (devices, usually) show up in most
subsystems, but they are organized differently.
Other terms will be defined as we come to them.
Sysfs is a virtual filesystem which provides a userspace-visible
representation of the device model. The device model and sysfs are
sometimes confused with each other, but they are distinct entities. The
device model functions just fine without sysfs (but the reverse is not
The sysfs filesystem is usually mounted on /sys; for readers
without a 2.6 system at hand, an example
/sys hierarchy from a simple system is available. The top-level
directories there correspond to the known subsystems in the model. The
full device model data structure can be seen by looking at the entries and
links within each subsystem. Thus, for example, the first IDE disk on a
particular system, being a device, would appear as:
But that device appears (in symbolic link form) under other subsystems as:
And, additionally, the IDE controller can be found as:
Within the disk's own sysfs directory (under /devices), the link
block points back at /sys/block/hda. As was said before, it
is a complicated data structure.
Driver writers generally need not worry about sysfs; it is magically
created and implemented by the driver model and bus driver code. The one
exception comes about when it comes to exporting attributes via
sysfs. These attributes represent some aspect of how the device and/or its
driver operate; they may or may not be writeable from user space. Sysfs is
now the preferred way (over /proc or ioctl()) to export
these variables to user space. The next article
in the series looks at how to manage attributes.
Even though most driver writers will never have to manipulate a kobject
directly, it is hard to dig very deeply into the driver model without
encountering them. A kobject
is a simple representation of data relevant
to any object found in the system; in a true object-oriented language, this
would be the class that most others inherit from. Kobjects contain the
attributes that, it is expected, most objects in the system will need: a
name, reference count, parent, and type. Almost any object related to the
device model will have a kobject buried deeply inside it somewhere.
A kset is a container for a set of kobjects of identical type.
Ksets belong to a subsystem (but a subsystem can hold more than one kset).
Among other things, ksets control how the system responds to hotplug events
- the addition (or removal) of an entry to (or from) the set.
Together, kobjects and ksets make up much of the glue that holds the driver
model structure together. A separate
article in this series covers kobjects and ksets in detail.
to post comments)