linux device model之我见

      纪晓岚曾经说：“世间的道理与事情，都在古人的书中说尽，现在如再著述，仍然超不过古人的范围，又何必再多著述。”于是他一生之中，从不著书，只是编书--整理前人的典籍，将中国文化作系统的分类，以便于以后的学者们学习。自己的著作只有『阅微草堂笔记』一册而已。

      linux设备模型也是如此，这个东西本来就是老外发明的，而且英文相关资料也足够详实明了，我在此不多赘言，只将资料整理于此。

      在Linux Kernel Development(Second Edition)，linux device drivers（third edition），Understanding the Linux Kernel（third edition）中都有关于linux device model的章节，其中linux device drivers（third edition）中介绍最为详实，在第十四章。[这三本可以从这里下载]

      其实所有关于linux device model的文章不过乎两点，一个是关于Kobjects, Ksets,Ktype，另一个就是关于sysfs，里面会介绍它的device,bus,class等目录。在linux device drivers还有一章14.6. Putting It All Together很好，使我们更加清晰的了解一个设备或驱动注册的整个过程发生了什么。

     网路上fudan_abc的复旦人甲曾经在“我是u盘”里也讲过设备模型(在linux内核修炼之道里也有总结)，不过感觉幽默有余，而逻辑不足，不如书中讲的好，虽然有些枯燥。

     资源差不多都在上面，万千精彩还等你去发现。正巧我在lwn上面发现了一个不错的overview，建议你去看原文，因为上面有几个有用的链接，这里只作摘抄存档。

Driver porting: Device model overview

                                                                                                                              [Posted May 7, 2003 by corbet]

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.