Driver porting: Device model overview

This article is part of the LWN Porting Drivers to 2.6 series. 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 as well. The device model presents a bit of a steep learning curve when first encountered. 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. device A physical or virtual object which attaches to a (possibly virtual) bus. driver A software entity which may probe for and be bound to devices, and which can perform certain management functions. bus A device which serves as an attachment point for other devices. class A particular type of device which can be expected to perform in certain ways. Classes might include disks, partitions, serial ports, etc. subsystem 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 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 true). 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: /sys/devices/pci0/00:11.1/ide0/0.0 But that device appears (in symbolic link form) under other subsystems as: /sys/block/hda/device /sys/bus/ide/devices/0.0 And, additionally, the IDE controller can be found as: /sys/bus/pci/devices/0.11.1 /sys/bus/pci/drivers/VIA IDE/00:11.1 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. Kobjects 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. No comments have been posted. Post one now