- 论坛徽章:
- 0
|
Device Drivers设备驱动这是一个基本的类型
struct device_driver {
char * name;
struct bus_type * bus;
struct completion unloaded;
struct kobject kobj;
list_t devices;驱动支持的设备列表
struct module *owner;
int (*probe) (struct device * dev);
int (*remove) (struct device * dev);
int (*suspend) (struct device * dev, pm_message_t state);
int (*resume) (struct device * dev); };
Allocation ~~~~~~~~~~
Device drivers are statically allocated structures. Though there may be multiple devices in a system that a driver supports, struct device_driver represents the driver as a whole (not a particular device instance).
设备驱动是一个静态的数据结构。尽管可能存在多个设备使用同一个驱动，结构体struct_driver 是驱动的一个集合体不是单独的设备操作历程
Initialization ~~~~~~~~~~~~~~
The driver must initialize at least the name and bus fields. It should also initialize the devclass field (when it arrives), so it may obtain the proper linkage internally. It should also initialize as many of the callbacks as possible, though each is optional.
驱动的初始化最起码应该初始名称和所属於的bus.还要初始化设备类，这样他就可以包含proper linkage.同时它应该初始化尽可能多的调用函数，尽管这些选项是可以选择的。
Declaration ~~~~~~~~~~~解释
As stated above, struct device_driver objects are statically allocated. Below is an example declaration of the eepro100 driver. This declaration is hypothetical only; it relies on the driver being converted completely to the new model. 一个例子
static struct device_driver eepro100_driver = {
.name = "eepro100",
.bus = &pci_bus_type,
.probe = eepro100_probe,
.remove = eepro100_remove,
.suspend = eepro100_suspend,
.resume = eepro100_resume, };
Most drivers will not be able to be converted completely to the new model because the bus they belong to has a bus-specific structure with bus-specific fields that cannot be generalized.
大部分的驱动是不能完全转化成一个新型的模块的，因为它所属于的总线有一个专门的结构bus-specific，这个结构是不能一般化的。（移植性）
The most common example of this are device ID structures. A driver typically defines an array of device IDs that it supports. The format of these structures and the semantics for comparing device IDs are completely bus-specific.
最普通的例子是设备id 结构。一个驱动会定义一个他所支持的设备的id列表。匹配设备时使用的结构的格式和语法是完全依赖于bus-specific的。
Defining them as bus-specific entities would sacrifice type-safety, so we keep bus-specific structures around.
把他们定义成bus-specific的形式会得到（类型的安全？），所以我们到处使用这个结构
Bus-specific drivers should include a generic struct device_driver in the definition of the bus-specific driver. Like this:
Bus-specific 驱动应该包含一个原始的结构体device_driver在定义bus_specific 驱动的时候，像这样
struct pci_driver
{ const struct pci_device_id *id_table;
struct device_driver driver; };
A definition that included bus-specific fields would look like (using the eepro100 driver again):
static struct pci_driver eepro100_driver = {
.id_table = eepro100_pci_tbl,
.driver= {
.name = "eepro100",
.bus = &pci_bus_type,
.probe = eepro100_probe,
.remove = eepro100_remove,
.suspend = eepro100_suspend,
.resume = eepro100_resume,
},
};
Some may find the syntax of embedded struct initialization awkward or even a bit ugly. So far, it's the best way we've found to do what we want...
人长得丑点，但作用很好。（我也很丑，可差距为什么就这么大那？）
Registration ~~~~~~~~~~~~注册
int driver_register(struct device_driver * drv);
The driver registers the structure on startup. For drivers that have no bus-specific fields (i.e. don't have a bus-specific driver structure), they would use driver_register and pass a pointer to their struct device_driver object.
没有bus_specific的驱动函数可以使用上面的函数注册。会返回一个指向这个驱动的指针
Most drivers, however, will have a bus-specific structure and will need to register with the bus using something like pci_driver_register.
如果有bus_specific那么需要使用针对特定bus的注册函数例如pci_driver_register.
It is important that drivers register their driver structure as early as possible. Registration with the
core initializes several fields in the struct device_driver object, including the reference count and the lock. These fields are assumed to be valid at all times and may be used by the device model core or the bus driver.
驱动应该尽可能早的注册他们的驱动结构体。注册的时候内核会初始化驱动对象的引用次数锁等域。这些域被假设成总是有效的并可以被内核驱动模块或总线驱动使用
Transition Bus Drivers ~~~~~~~~~~~~~~~~~~~~~~移植总线驱动
By defining wrapper functions, the transition to the new model can be made easier. Drivers can ignore the generic structure altogether and let the bus wrapper fill in the fields. For the callbacks, the bus can define generic callbacks that forward the call to the bus-specific callbacks of the drivers. 通过函数功能打包，可以增加移植性。驱动可以忽略原始的结构而让总线包填充这些域，不翻译了
This solution is intended to be only temporary. In order to get class information in the driver, the drivers must be modified anyway. Since converting drivers to the new model should reduce some infrastructural complexity and code size, it is recommended that they are converted as class information is added.
Access ~~~~~~进入
Once the object has been registered, it may access the common fields of the object, like the lock and the list of devices.
int driver_for_each_dev(struct device_driver * drv, void * data,
int (*callback)(struct device * dev, void * data));
The devices field is a list of all the devices that have been bound to the driver. The LDM core provides a helper function to operate on all the devices a driver controls. This helper locks the driver on each node access, and does proper reference counting on each device as it accesses it.
设备域是一个绑定了的设备列表。Ldm内核提供了帮助功能去管理一个驱动所控制的设备。
Helper会锁定驱动当进入每个节点的时候，可以对每个设备作引用次数的探测
sysfs ~~~驱动注册时文件系统上的改变
When a driver is registered, a sysfs directory is created in its bus's directory. In this directory, the driver can export an interface to userspace to control operation of the driver on a global basis; e.g. toggling debugging output in the driver.
A future feature of this directory will be a 'devices' directory. This directory will contain symlinks to the directories of devices it supports.
Callbacks ~~~~~~~~~调用
int (*probe) (struct device * dev);
The probe() entry is called in task context, with the bus's rwsem locked and the driver partially bound to the device. Drivers commonly use container_of() to convert "dev" to a bus-specific type, both in probe() and other routines. That type often provides device resource data, such as pci_dev.resource[] or platform_device.resources, which is used in addition to dev->platform_data to initialize the driver.
This callback holds the driver-specific logic to bind the driver to a given device. That includes verifying that the device is present, that it's a version the driver can handle, that driver data structures can be allocated and initialized, and that any hardware can be initialized. Drivers often store a pointer to their state with dev_set_drvdata(). When the driver has successfully bound itself to that device, then probe() returns zero and the driver model code will finish its part of binding the driver to that device.
A driver's probe() may return a negative errno value to indicate that the driver did not bind to this device, in which case it should have released all reasources it allocated.
int (*remove) (struct device * dev);
remove is called to unbind a driver from a device. This may be called if a device is physically removed from the system, if the driver module is being unloaded, during a reboot sequence, or in other cases.
It is up to the driver to determine if the device is present or not. It should free any resources allocated specifically for the device; i.e. anything in the device's driver_data field.
If the device is still present, it should quiesce the device and place it into a supported low-power state.
int (*suspend) (struct device * dev, pm_message_t state);
suspend is called to put the device in a low power state.
挂起设备
int (*resume) (struct device * dev);
Resume is used to bring a device back from a low power state.
Attributes ~~~~~~~~~~
struct driver_attribute {
struct attribute attr;
ssize_t (*show)(struct device_driver *, char * buf, size_t count, loff_t off);
ssize_t (*store)(struct device_driver *, const char * buf, size_t count, loff_t off); };
Device drivers can export attributes via their sysfs directories. Drivers can declare attributes using a DRIVER_ATTR macro that works identically to the DEVICE_ATTR macro.
Example:
DRIVER_ATTR(debug,0644,show_debug,store_debug);
This is equivalent to declaring:
struct driver_attribute driver_attr_debug;
This can then be used to add and remove the attribute from the driver's directory using:
int driver_create_file(struct device_driver *, struc
The Linux Kernel Device Mode 内核设备模型
Patrick Mochel
26 August 2002
Overview ~~~~~~~~
This driver model is a unification of all the current, disparate driver models that are currently in the kernel.
现在驱动模型已经统一，在内核中很轻视驱动的模型是一个潮流
It is intended to augment the bus-specific drivers for bridges and devices by consolidating a set of data and operations into globally accessible data structures.
现在通过固化一系列的数据和操作到全局可进入的数据结构来增加bus_specific 驱动
Current driver models implement some sort of tree-like structure (sometimes just a list) for the devices they control. But, there is no linkage between the different bus types.
现在的驱动模块把他们控制的设备描述为一些树状的结构（有时候是一些列表）
A common data structure can provide this linkage with little overhead: when a bus driver discovers a particular device, it can insert it into the global tree as well as its local tree. In fact, the local tree becomes just a subset of the global tree.当一个总线驱动发现一个设备的时候即可把它插入全局树，也可以把它插入到当地数。实际上当地树变成了全局树的一个分支。
Common data fields can also be moved out of the local bus models into the global model. Some of the manipulations of these fields can also be consolidated. Most likely, manipulation functions will become a set of helper functions, which the bus drivers wrap around to include any bus-specific items.
The common device and bridge interface currently reflects the goals of the modern PC: namely the ability to do seamless Plug and Play, power management, and hot plug. (The model dictated by Intel and Microsoft (read: ACPI) ensures us that any device in the system may fit any of these criteria.)
现在的通用设备都反映了一个现代pc的目的：热插拔。
In reality, not every bus will be able to support such operations. But, most buses will support a majority of those operations, and all future buses will. In other words, a bus that doesn't support an operation is the exception, instead of the other way around.
实际上，不是每种总线都支持这种操作。但是，大部分的总线会支持总线应该有的主要的操作
Downstream Access ~~~~~~~~~~~~~~~~~向下访问
Common data fields have been moved out of individual bus layers into a common data structure. But, these fields must still be accessed by the bus layers, and sometimes by the device-specific drivers.
通用的数据域已经移出总线层到一个通用数据结构。但是这些域仍经可以被总线层和device-specific 访问
Other bus layers are encouraged to do what has been done for the PCI layer. struct pci_dev now looks like this:
struct pci_dev { ...
struct device device; };
Note first that it is statically allocated. This means only one allocation on device discovery. Note also that it is at the _end_ of struct pci_dev. This is to make people think about what they're doing when switching between the bus driver and the global driver; and to prevent against mindless casts between the two.
The PCI bus layer freely accesses the fields of struct device. It knows about the structure of struct pci_dev, and it should know the structure of struct device. PCI devices that have been converted generally do not touch the fields of struct device. More precisely, device-specific drivers should not touch fields of struct device unless there is a strong compelling reason to do so.
This abstraction is prevention of unnecessary pain during transitional phases. If the name of the field changes or is removed, then every downstream driver will break. On the other hand, if only the bus layer (and not the device layer) accesses struct device, it is only that layer that needs to change.上面主要是说，总线层可以自由的进入域 device,如果这域的结构有所改变，那么想朝下访问的驱动都会被打断，在另一方面就是说如果设备层不进入device那么只需改变一下总线层就可以了
User Interface ~~~~~~~~~~~~~~用户接口
By virtue of having a complete hierarchical view of all the devices in the system, exporting a complete hierarchical view to userspace becomes relatively easy. This has been accomplished by implementing a special purpose virtual file system named sysfs. It is hence possible for the user to mount the whole sysfs filesystem anywhere in userspace.
虚拟文件系统已经提供了一个所有设备的层次结构用户接口
This can be done permanently by providing the following entry into the /etc/fstab (under the provision that the mount point does exist, of course):
none /sys sysfs defaults 0 0
Or by hand on the command line:
# mount -t sysfs sysfs /sys
Whenever a device is inserted into the tree, a directory is created for it. This directory may be populated at each layer of discovery - the global layer, the bus layer, or the device layer.
无论什么时候当一个设备被插入到树中，一个目录就会创建。这个目录可能被创建在发现他的任何层，全局层，总线层，设备层
The global layer currently creates two files - 'name' and 'power'. The former only reports the name of the device. The latter reports the current power state of the device. It will also be used to set the current power state.
全局层就现在创建了两个文件，名字和能量。第一个文件用来描述设备的名称。能量文件主要是用来描述设备的能量情况。同时用来设置设备的能量状态。
The bus layer may also create files for the devices it finds while probing the bus. For example, the PCI layer currently creates 'irq' and 'resource' files for each PCI device.
总线层可能也为它发现的设备创建文件当探测总线的时候。例如，pci层会为每一个pci设备创建irp和rescoure文件。
A device-specific driver may also export files in its directory to expose device-specific data or tunable interfaces.
设备层的驱动也会为操作device_specific数据和tunable接口引进一些文件
More information about the sysfs directory layout can be found in the other documents in this directory and in the file Documentation/filesystems/sysfs.txt.
下面讲的是自治型型设备和驱动的知识
Platform Devices and Drivers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Platform devices ~~~~~~~~~~~~~~~~ Platform devices are devices that typically appear as autonomous entities in the system. This includes legacy port-based devices and host bridges to peripheral buses.
这类设备主要是基于端口的设备，和与外围总线挂接的桥（不知道这样对不对）
Platform drivers ~~~~~~~~~~~~~~~~ Drivers for platform devices are typically very simple and unstructured.
简单无组织
Either the device was present at a particular I/O port and the driver was loaded, or it was not. There was no possibility of hotplugging or alternative discovery besides probing at a specific I/O address and expecting a specific response.
不能进行热插拔，除非使用探测函数
Other Architectures, Modern Firmware, and new Platforms ~~~~~~~~~~~~~~~~ 其他的一些补充说明
These devices are not always at the legacy I/O ports. This is true on other architectures and on some modern architectures. In most cases, the drivers are modified to discover the devices at other well-known ports for the given platform. However, the firmware in these systems does usually know where exactly these devices reside, and in some cases, it's the only way of discovering them.
The Platform Bus ~~~~~~~~~~~~~~~~ A platform bus has been created to deal with these issues. First and foremost, it groups all the legacy devices under a common bus, and gives them a common parent if they don't already have one.
But, besides the organizational benefits, the platform bus can also accommodate firmware-based enumeration.
Device Discovery ~~~~~~~~~~~~~~~~ The platform bus has no concept of probing for devices. Devices discovery is left up to either the legacy drivers or the firmware. These entities are expected to notify the platform of devices that it discovers via the bus's add() callback:
platform_bus.add(parent,bus_id).
Bus IDs ~~~~~~~ Bus IDs are the canonical names for the devices. There is no globally standard addressing mechanism for legacy devices. In the IA-32 world, we have Pnp IDs to use, as well as the legacy I/O ports. However, neither tell what the device really is or have any meaning on other platforms.
Since both PnP IDs and the legacy I/O ports (and other standard I/O ports for specific devices) have a 1:1 mapping, we map the platform-specific name or identifier to a generic name (at least within the scope of the kernel).
For example, a serial driver might find a device at I/O 0x3f8. The ACPI firmware might also discover a device with PnP ID (_HID) PNP0501. Both correspond to the same device and should be mapped to the canonical name 'serial'.
The bus_id field should be a concatenation of the canonical name and the instance of that type of device. For example, the device at I/O port 0x3f8 should have a bus_id of "serial0". This places the responsibility of enumerating devices of a particular type up to the discovery mechanism. But, they are the entity that should know best (as opposed to the platform bus driver).
Drivers ~~~~~~~ Drivers for platform devices should have a name that is the same as the canonical name of the devices they support. This allows the platform bus driver to do simple matching with the basic data structures to determine if a driver supports a certain device.
For example, a legacy serial driver should have a name of 'serial' and register itself with the platform bus. 命名的时候需要与设备名一样
Driver Binding ~~~~~~~~~~~~~~ Legacy drivers assume they are bound to the device once they start up and probe an I/O port.
驱动假设他们被绑定到设备一旦他们被启动并且探测一个io端口。
Divorcing them from this will be a difficult process. However, that shouldn't prevent us from implementing firmware-based enumeration.
The firmware should notify the platform bus about devices before the legacy drivers have had a chance to load. Once the drivers are loaded, they driver model core will attempt to bind the driver to any previously-discovered devices. Once that has happened, it will be free to discover any other devices it pleases.
移植驱动到新的驱动模型
Porting Drivers to the New Driver Model
Patrick Mochel
7 January 2003
Overview
Please refer to Documentation/driver-model/*.txt for definitions of various driver types and concepts.
Most of the work of porting devices drivers to the new model happens at the bus driver layer. This was intentional, to minimize the negative effect on kernel drivers, and to allow a gradual transition of bus drivers.
In a nutshell, the driver model consists of a set of objects that can be embedded in larger, bus-specific objects. Fields in these generic objects can replace fields in the bus-specific objects.
The generic objects must be registered with the driver model core. By doing so, they will exported via the sysfs filesystem. sysfs can be mounted by doing
# mount -t sysfs sysfs /sys
The Process 过程
Step 0: Read include/linux/device.h for object and function definitions. 读这个文件
Step 1: Registering the bus driver. 注册总线驱动
- Define a struct bus_type for the bus driver .定义总线类型
struct bus_type pci_bus_type = { .name = "pci", };
- Register the bus type. 注册总线类型这个会被
- 初始化函数中完成
- This should be done in the initialization function for the bus type, which is usually the module_init(), or equivalent, function.
static int __init pci_driver_init(void) { return bus_register(&pci_bus_type); }
subsys_initcall(pci_driver_init);
The bus type may be unregistered (if the bus driver may be compiled
as a module) by doing:
bus_unregister(&pci_bus_type);
- Export the bus type for others to use. 引进总线类型
Other code may wish to reference the bus type, so declare it in a shared header file and export the symbol.
From include/linux/pci.h:
extern struct bus_type pci_bus_type;
From file the above code appears in:
EXPORT_SYMBOL(pci_bus_type);
- This will cause the bus to show up in /sys/bus/pci/ with two subdirectories: 'devices' and 'drivers'.
# tree -d /sys/bus/pci/ /sys/bus/pci/ |-- devices `-- drivers
Step 2: Registering Devices. 注册设备
struct device represents a single device. It mainly contains metadata describing the relationship the device has to other entities.
- Embedd a struct device in the bus-specific device type. 在bus-specific 中嵌入一个设备
struct pci_dev { ...
struct device dev; /* Generic device interface */ ... };
It is recommended that the generic device not be the first item in
the struct to discourage programmers from doing mindless casts
between the object types. Instead macros, or inline functions,
should be created to convert from the generic object type.
#define to_pci_dev(n) container_of(n, struct pci_dev, dev)
or
static inline struct pci_dev * to_pci_dev(struct kobject * kobj) { return container_of(n, struct pci_dev, dev); }
This allows the compiler to verify type-safety of the operations
that are performed (which is Good).
- Initialize the device on registration. 初始化设备
When devices are discovered or registered with the bus type, the
bus driver should initialize the generic device. The most important things to initialize are the bus_id, parent, and bus fields.
The bus_id is an ASCII string that contains the device's address on the bus. The format of this string is bus-specific. This is
necessary for representing devices in sysfs.
parent is the physical parent of the device. It is important that
the bus driver sets this field correctly.
The driver model maintains an ordered list of devices that it uses
for power management. This list must be in order to guarantee that devices are shutdown before their physical parents, and vice versa.
The order of this list is determined by the parent of registered devices.
Also, the location of the device's sysfs directory depends on a
device's parent. sysfs exports a directory structure that mirrors
the device hierarchy. Accurately setting the parent guarantees that sysfs will accurately represent the hierarchy.
The device's bus field is a pointer to the bus type the device
belongs to. This should be set to the bus_type that was declared
and initialized before.
Optionally, the bus driver may set the device's name and release fields.
The name field is an ASCII string describing the device, like
"ATI Technologies Inc Radeon QD"
The release field is a callback that the driver model core calls
when the device has been removed, and all references to it have
been released. More on this in a moment.
- Register the device. 注册设备
Once the generic device has been initialized, it can be registered with the driver model core by doing:
device_register(&dev->dev);
It can later be unregistered by doing:
device_unregister(&dev->dev);
This should happen on buses that support hotpluggable devices.
If a bus driver unregisters a device, it should not immediately free it. It should instead wait for the driver model core to call the
device's release method, then free the bus-specific object.
(There may be other code that is currently referencing the device structure, and it would be rude to free the device while that is happening).
When the device is registered, a directory in sysfs is created.
The PCI tree in sysfs looks like:
/sys/devices/pci0/ |-- 00:00.0 |-- 00:01.0 | `-- 01:00.0 |-- 00:02.0 | `-- 02:1f.0 | `-- 03:00.0 |-- 00:1e.0 | `-- 04:04.0 |-- 00:1f.0 |-- 00:1f.1 | |-- ide0 | | |-- 0.0 | | `-- 0.1 | `-- ide1 | `-- 1.0 |-- 00:1f.2 |-- 00:1f.3 `-- 00:1f.5
Also, symlinks are created in the bus's 'devices' directory
that point to the device's directory in the physical hierarchy.
/sys/bus/pci/devices/ |-- 00:00.0 -> ../../../devices/pci0/00:00.0 |-- 00:01.0 -> ../../../devices/pci0/00:01.0 |-- 00:02.0 -> ../../../devices/pci0/00:02.0 |-- 00:1e.0 -> ../../../devices/pci0/00:1e.0 |-- 00:1f.0 -> ../../../devices/pci0/00:1f.0 |-- 00:1f.1 -> ../../../devices/pci0/00:1f.1 |-- 00:1f.2 -> ../../../devices/pci0/00:1f.2 |-- 00:1f.3 -> ../../../devices/pci0/00:1f.3 |-- 00:1f.5 -> ../../../devices/pci0/00:1f.5 |-- 01:00.0 -> ../../../devices/pci0/00:01.0/01:00.0 |-- 02:1f.0 -> ../../../devices/pci0/00:02.0/02:1f.0 |-- 03:00.0 -> ../../../devices/pci0/00:02.0/02:1f.0/03:00.0 `-- 04:04.0 -> ../../../devices/pci0/00:1e.0/04:04.0
Step 3: Registering Drivers. 注册驱动
struct device_driver is a simple driver structure that contains a set of operations that the driver model core may call.
- Embed a struct device_driver in the bus-specific driver.
Just like with devices, do something like:
struct pci_driver { ...
struct device_driver driver; };
- Initialize the generic driver structure.
When the driver registers with the bus (e.g. doing pci_register_driver()), initialize the necessary fields of the driver: the name and bus
fields.
- Register the driver. 注册
After the generic driver has been initialized, call
driver_register(&drv->driver);
to register the driver with the core.
When the driver is unregistered from the bus, unregister it from the core by doing:
driver_unregister(&drv->driver);
Note that this will block until all references to the driver have
gone away. Normally, there will not be any.
- Sysfs representation.
Drivers are exported via sysfs in their bus's 'driver's directory.
For example:
/sys/bus/pci/drivers/ |-- 3c59x |-- Ensoniq AudioPCI |-- agpgart-amdk7 |-- e100 `-- serial
Step 4: Define Generic Methods for Drivers. 定义操作函数
struct device_driver defines a set of operations that the driver model core calls. Most of these operations are probably similar to operations the bus already defines for drivers, but taking different parameters.
It would be difficult and tedious to force every driver on a bus to simultaneously convert their drivers to generic format. Instead, the bus driver should define single instances of the generic methods that forward call to the bus-specific drivers. For instance:
static int pci_device_remove(struct device * dev) { struct pci_dev * pci_dev = to_pci_dev(dev);
struct pci_driver * drv = pci_dev->driver;
if (drv) { if (drv->remove) drv->remove(pci_dev); pci_dev->driver = NULL; }
return 0; }
The generic driver should be initialized with these methods before it is registered.
/* initialize common driver fields */
drv->driver.name = drv->name;
drv->driver.bus = &pci_bus_type;
drv->driver.probe = pci_device_probe;
drv->driver.resume = pci_device_resume;
drv->driver.suspend = pci_device_suspend;
drv->driver.remove = pci_device_remove;
/* register with core */
driver_register(&drv->driver);
Ideally, the bus should only initialize the fields if they are not already set. This allows the drivers to implement their own generic methods.
Step 5: Support generic driver binding. 驱动绑定
The model assumes that a device or driver can be dynamically registered with the bus at any time. When registration happens, devices must be bound to a driver, or drivers must be bound to all devices that it supports.
这个是很有意思的特点
A driver typically contains a list of device IDs that it supports. The bus driver compares these IDs to the IDs of devices registered with it. The format of the device IDs, and the semantics for comparing them are bus-specific, so the generic model does attempt to generalize them.
Instead, a bus may supply a method in struct bus_type that does the comparison:
int (*match)(struct device * dev, struct device_driver * drv);
match should return '1' if the driver supports the device, and '0' otherwise.
When a device is registered, the bus's list of drivers is iterated over. bus->match() is called for each one until a match is found.
当注册设备的时候，总线的驱动列表会被遍历，并被执行bus->match()看看有没有符合的去驱动 ，如果有就绑定
When a driver is registered, the bus's list of devices is iterated over. bus->match() is called for each device that is not already claimed by a driver.
当一个驱动被注册的时候，总线的设备列表会被遍历，每个设备都会用bus->match检查，看看是否被支持如果有就帮定
When a device is successfully bound to a driver, device->driver is set, the device is added to a per-driver list of devices, and a symlink is created in the driver's sysfs directory that points to the device's physical directory:
绑定的过程就是把设备的device->driver设置
设备加到pre-drvier 列表，并且一个符号连接在驱动的目录创建，这个符号连接指向设备的实际目录
/sys/bus/pci/drivers/ |-- 3c59x | `-- 00:0b.0 -> ../../../../devices/pci0/00:0b.0 |-- Ensoniq AudioPCI |-- agpgart-amdk7 | `-- 00:00.0 -> ../../../../devices/pci0/00:00.0 |-- e100 | `-- 00:0c.0 -> ../../../../devices/pci0/00:0c.0 `-- serial
This driver binding should replace the existing driver binding mechanism the bus currently uses.
Step 6: Supply a hotplug callback. 提供一个热插拔调用
Whenever a device is registered with the driver model core, the userspace program /sbin/hotplug is called to notify userspace. Users can define actions to perform when a device is inserted or removed.
The driver model core passes several arguments to userspace via environment variables, including
- ACTION: set to 'add' or 'remove'
- DEVPATH: set to the device's physical path in sysfs.
A bus driver may also supply additional parameters for userspace to consume. To do this, a bus must implement the 'hotplug' method in struct bus_type:
int (*hotplug) (struct device *dev, char **envp, int num_envp, char *buffer, int buffer_size);
This is called immediately before /sbin/hotplug is executed. 这个函数会被调用在/sbin/hotplug 执行以前
Step 7: Cleaning up the bus driver. 后面的有时间再说
The generic bus, device, and driver structures provide several fields that can replace those defined privately to the bus driver.
- Device list.
struct bus_type contains a list of all devices registered with the bus type. This includes all devices on all instances of that bus type. An internal list that the bus uses may be removed, in favor of using this one.
The core provides an iterator to access these devices.
int bus_for_each_dev(struct bus_type * bus, struct device * start, void * data, int (*fn)(struct device *, void *));
- Driver list.
struct bus_type also contains a list of all drivers registered with it. An internal list of drivers that the bus driver maintains may be removed in favor of using the generic one.
The drivers may be iterated over, like devices:
int bus_for_each_drv(struct bus_type * bus, struct device_driver * start, void * data, int (*fn)(struct device_driver *, void *));
Please see drivers/base/bus.c for more information.
- rwsem
struct bus_type contains an rwsem that protects all core accesses to the device and driver lists. This can be used by the bus driver internally, and should be used when accessing the device or driver lists the bus maintains.
- Device and driver fields.
Some of the fields in struct device and struct device_driver duplicate fields in the bus-specific representations of these objects. Feel free to remove the bus-specific ones and favor the generic ones. Note though, that this will likely mean fixing up all the drivers that reference the bus-specific fields (though those should all be 1-line changes).
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/94887/showart_1913348.html |
|
免费注册
发表于 2009-04-28 19:11