The Linux Kernel Driver Model
Patrick Mochel
Open Source Development Lab
mochel@osdl
Abstract
A new device driver model has been designed and developed for the2.5version of the Linux Kernel.The original intent of this model was to provide a means to generically reprent and operate on every device in a computer.This would allow modern power management routines to perform properly ordered suspend and resume operations on the entire device space during system power state transitions.
During the integration of the initial model,it became apparent that many more concepts related to devices besides power management information could be generalized and shared.The new driver model has evolved to provide generic reprentations of veral objects,including:
•Devices
•Device drivers
•Bus drivers
•Device Class
•Device Interfaces有趣的惩罚方式
The model also provides a t of functions to operate on each of tho objects. This has provided the opportunity to consolidate and simplify a large quantity of kernel code and data structures.
The new driver model has been included in the mainstream kernel,since version2.5.1,and continues to mature and evolve as more drivers are converted to exploit its infrastructure.
This document describes the design and implementation of the new driver model.It covers the description of the objects and their programming interfaces, as well as their conceptual and programmatic interactions with one another.It also includes appendices on the kobject infrastructure and the sysfsfilesystem. The are two important features that were developed as a result of the driver model,yet were divorced from the model becau of their more general purpo. They are covered in this document in the context of how they are ud in the driver model.天行健君子以自强不息什么意思
虎配什么生肖最好
1
1Introduction
Theory
The driver model was created by analyzing the behavior of the PCI and USB bus drivers.The bus are ubiquitous in contemporary computer systems,and reprent the majority of the devices that the kernel supports.They contain the most mature support for dynamic addition,removal,and power management of devices and drivers.The features had already been permeating other kernel bus drivers,with inspiration from the PCI and USB subsystems.They were considered appropriate bas of assumptions,and are described below.
The assumptions hold true for the majority of instances of objects repre-nted by the driver model.The minority of objects are considered exceptions, and must work around the driver model assumptions.如何放松肌肉
A bus driver is a t of code that communicates with a peripheral bus of a certain type.Some examples of bus drivers in the kernel include:•PCI
•USB
•SCSI
•IDE
•PCMCIA
Bus drivers maintain a list of devices that are prent on all instances of that bus type,and a list of registered drivers.A bus driver is compile-time option,and may usually be compiled as a module.There will never be multiple instances of a driver for the same bus type at the same time.Most,if not all, of its internal data structures are statically allocated.
A bus instance reprents the prence of a bus of a particular type,such as PCI Bus0.They are dynamically allocated when the bus instance is discovered. They contain a list of devices,as well as data describing the connection to the device.Bus instances are not currently reprented in the driver model. However,they are mentioned here to note the distinction between them and bus driver objects.
During startup,a bus driver discovers instances of its bus type.It scans the bus for prent devices a
nd allocates data structures to describe each device. Most of this information is bus-specific,such as the bus address of the device and device identification information.The bus driver need not know of the function the device performs.This object is inrted into the bus’s list of devices,and the bus driver attempts to bind it to a device driver.
A device class describes a function that a device performs,regardless of the bus on which a particular device resides.Examples of device class are:•Audio output devices拼音ui怎么发音
•Network devices
2
•Disks
•Input devices
A device class driver maintains lists of device and drivers that belong to that class.They are optional bodies of code that may be compiled as a module.Its data structures are statically allocated.A device class defines object types to describe the devices registered wit h it.The objects define the devices in the context of the class only,since class are independent of a device’s bus type.
成都去九寨沟
A device class is characterized by a t of interfaces that allow ur process to communicate with devices of their type.An interface defines a protocol for communicating with tho devices,which is characterized in a ur space device node.A class may contain multiple interfaces for communicating with devices, though the devices and drivers of that class may not support all the interfaces of the class.
A device driver is a body of code that implements one or more interfaces of a device class for a t of devices on a specific bus type.They contain some statically allocated structures to describe the driver to its bus and class,and to maintain a list of bound devices.
During startup,a driver registers with its bus,and the bus inrts the driver into its internal list of drivers.The bus then attempts to bind the driver to the bus’s list of devices.A bus compares a list of bus-specific device ID numbers that it supports with the ID numbers of the devices on the bus.If a match is made,the device is’attached’to the driver.The driver allocates a driver-specific object to describe the device.This usually includes a class-specific object as well, which the driver us to register the device with it’s class.
Infrastructure
The driver model provides a t of objects to reprent the entities described above.Previously,the kernel reprentations of the objects,especially devices, have varied greatly bad on the functionality that they provide and the bus type forwhich they are designed.Much of this information is specific to the type of object,though some can be generically encoded,which are what compo the driver model objects.
路由器设置局域网Most of the members of driver model objects contian meta data describing the object,and linkage information to reprent membership in groups and lists of subordinate objects.The driver model object definitions can be found in the headerfile include/linux/device.h.
The driver model also provides a t of functions to operate on each object. The functions are referred to the’driver model core’through this document. They are implemented in drivers/ba/in the kernel source tree.Each t of operations is object-specific and described in detail with the objects in their respective ctions.However,there are some commonalities between objects that are reflected in the functions of the core.The are described here to provide perspective on the model,and to avoid repeating the purpos in each ction.
3
Every driver model object supports dynamic addition and removal.Each object has register()and unregister()functions specific to that object.Regis-tration initializes the object,inrts it into a list of similar objects,and creates a directory for the object in the sysfsfilesystem.Registration occurs when a device is discovered or a module containing a device,bus,or class driver is in-rted.Unregistration occurs when a driver’s module is unloaded or a device is physically removed.Unregistration removes the object’s sysfs directory and deletes it from the list of similar objects.
To support dynamic removal,each object contains a reference count that can be adjusted by object-specific get()and put()functions.The get()routine should be called for an object before it is ud in ()returns a reference to the object.The put()routine should be called after a function is done using an object.It has no return value.
If,and only if,an object’s reference count reaches0may the object be freed, or its module be unloaded.Another process may still hold a reference to the ob-ject when the object’s unregister()function returns.Blindly freeing an object’s memory could cau the other process to access invalid or reallocated memory. The method that the driver model us to prevent the bugs is described in the individual objects’ctions.
The similarities of driver model objects,and the amount of replicated code to perform similar operations on the objects prompted the effort to create a generic object type to be shared across not only driver model objects,butalso across all complex kernel objects that supported dynamic registration and reference counting.
A kobject generically describes an object.It may be embedded in larger data types to provide generic object meta data and a reference counting mech-anism.A subsystem reprents a t of kobjects.A kobject can be dynamically registered and unregistered with their subsystem.When a kobject is registered, it is initialized and inrted into its subsystem’s list of objects.A directory in sysfs,described below,is also created.Unregistration removes the sysfs direc-tory for the kobject and deletes it from its subsystem’s list.Kobjects also have a reference count and get()and put()operations to adjust it.A kobject may belong to only one subsystem,and a subsystem must contain only identically embedded kobjects.
The kobject functionality is very similar to the driver model core.The driver model functions have been adapted to u the kobject infrastructure,and some provide no more functionality than calling the associated kobject function.
The kobject and subsystem infrastructure is described in Appendix A.
The sysfsfilesystem was originally created as a means to export driver model objects and their attributes to ur space.It has since been integrated with the kobject infrastructure,so it can communicate directly with the generic object, allowing it to do reference counting on reprented objects.
All registered kobjects receive a directory in sysfs in a specific location bad on the kobject’s ancestry.This provides ur space with a meaningful object hi-erarchy in thefilesystem which can be navigated through using basicfile system tools,like ls(1),find(1),and grep(1).
4
Attributes of an object may be exported via sysfs,and are reprented as textfiles in thefilesystem.Sysfs provides a means for ur process to read and write attributes.The kernel exporters of attributes may define methods called by sysfs when a read or write operation is performed on an attributefile.
The sysfsfilesystem and its programming interface is discusd in Appendix B.
Summary
The new driver model implements a large amount of infrastructure for describing and operating on device-related objects.This infrastructure has been able to eliminate redundant kernel code and data structures,especially in the areas of object reference counting and list membership management.This reduces the complexity of device,bus and class drivers,making them easier to write and easier to read.The consolidation of data structures also makes it easier to implement common functions to operate on objects of traditionally different objects.
While this document describes the ba objects and operations of the driver model,there are many things it omits.It does not describe how it is exploited for the purpo of power management or implementing a dynamic and scalable device naming scheme.The topics are beyond the scope of this document and rerved for other discussions.
Similarly,this document only superficially describes the kobject infrastruc-ture and the sysfsfilesystem.The are included only to provide enough context to complete the discussion of the driver model,and are best covered in other documents.
2kobjects and subsystems
The kobject infrastructure was developed to consolidate common aspects of driver model objects.Th
e result is a simple object type designed to provide a foundation for more complex object types.Struct subsystem was created to describe and manage ts of kobjects.It was also created to consolidate and unify driver model objects and functions.
kobjects
Struct kobject provides basic object attributes in a structure that is designed to be embedded in larger structures.Subsystems that embed kobject may uits members,and the helpers for them,rather than defining their own.
When a kobject is registered,it should initialize the followingfields:
•name
•parent
狗咬狗打一成语5