Root/
1 | The Linux Kernel Device Model |
2 | |
3 | Patrick Mochel <mochel@digitalimplant.org> |
4 | |
5 | Drafted 26 August 2002 |
6 | Updated 31 January 2006 |
7 | |
8 | |
9 | Overview |
10 | ~~~~~~~~ |
11 | |
12 | The Linux Kernel Driver Model is a unification of all the disparate driver |
13 | models that were previously used in the kernel. It is intended to augment the |
14 | bus-specific drivers for bridges and devices by consolidating a set of data |
15 | and operations into globally accessible data structures. |
16 | |
17 | Traditional driver models implemented some sort of tree-like structure |
18 | (sometimes just a list) for the devices they control. There wasn't any |
19 | uniformity across the different bus types. |
20 | |
21 | The current driver model provides a common, uniform data model for describing |
22 | a bus and the devices that can appear under the bus. The unified bus |
23 | model includes a set of common attributes which all busses carry, and a set |
24 | of common callbacks, such as device discovery during bus probing, bus |
25 | shutdown, bus power management, etc. |
26 | |
27 | The common device and bridge interface reflects the goals of the modern |
28 | computer: namely the ability to do seamless device "plug and play", power |
29 | management, and hot plug. In particular, the model dictated by Intel and |
30 | Microsoft (namely ACPI) ensures that almost every device on almost any bus |
31 | on an x86-compatible system can work within this paradigm. Of course, |
32 | not every bus is able to support all such operations, although most |
33 | buses support a most of those operations. |
34 | |
35 | |
36 | Downstream Access |
37 | ~~~~~~~~~~~~~~~~~ |
38 | |
39 | Common data fields have been moved out of individual bus layers into a common |
40 | data structure. These fields must still be accessed by the bus layers, |
41 | and sometimes by the device-specific drivers. |
42 | |
43 | Other bus layers are encouraged to do what has been done for the PCI layer. |
44 | struct pci_dev now looks like this: |
45 | |
46 | struct pci_dev { |
47 | ... |
48 | |
49 | struct device dev; |
50 | }; |
51 | |
52 | Note first that it is statically allocated. This means only one allocation on |
53 | device discovery. Note also that it is at the _end_ of struct pci_dev. This is |
54 | to make people think about what they're doing when switching between the bus |
55 | driver and the global driver; and to prevent against mindless casts between |
56 | the two. |
57 | |
58 | The PCI bus layer freely accesses the fields of struct device. It knows about |
59 | the structure of struct pci_dev, and it should know the structure of struct |
60 | device. Individual PCI device drivers that have been converted to the current |
61 | driver model generally do not and should not touch the fields of struct device, |
62 | unless there is a strong compelling reason to do so. |
63 | |
64 | This abstraction is prevention of unnecessary pain during transitional phases. |
65 | If the name of the field changes or is removed, then every downstream driver |
66 | will break. On the other hand, if only the bus layer (and not the device |
67 | layer) accesses struct device, it is only that layer that needs to change. |
68 | |
69 | |
70 | User Interface |
71 | ~~~~~~~~~~~~~~ |
72 | |
73 | By virtue of having a complete hierarchical view of all the devices in the |
74 | system, exporting a complete hierarchical view to userspace becomes relatively |
75 | easy. This has been accomplished by implementing a special purpose virtual |
76 | file system named sysfs. It is hence possible for the user to mount the |
77 | whole sysfs filesystem anywhere in userspace. |
78 | |
79 | This can be done permanently by providing the following entry into the |
80 | /etc/fstab (under the provision that the mount point does exist, of course): |
81 | |
82 | none /sys sysfs defaults 0 0 |
83 | |
84 | Or by hand on the command line: |
85 | |
86 | # mount -t sysfs sysfs /sys |
87 | |
88 | Whenever a device is inserted into the tree, a directory is created for it. |
89 | This directory may be populated at each layer of discovery - the global layer, |
90 | the bus layer, or the device layer. |
91 | |
92 | The global layer currently creates two files - 'name' and 'power'. The |
93 | former only reports the name of the device. The latter reports the |
94 | current power state of the device. It will also be used to set the current |
95 | power state. |
96 | |
97 | The bus layer may also create files for the devices it finds while probing the |
98 | bus. For example, the PCI layer currently creates 'irq' and 'resource' files |
99 | for each PCI device. |
100 | |
101 | A device-specific driver may also export files in its directory to expose |
102 | device-specific data or tunable interfaces. |
103 | |
104 | More information about the sysfs directory layout can be found in |
105 | the other documents in this directory and in the file |
106 | Documentation/filesystems/sysfs.txt. |
107 | |
108 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9