Commit | Line | Data |
---|---|---|
4489f161 | 1 | ============================= |
1da177e4 | 2 | The Linux Kernel Device Model |
4489f161 | 3 | ============================= |
1da177e4 | 4 | |
ab11f899 | 5 | Patrick Mochel <mochel@digitalimplant.org> |
1da177e4 | 6 | |
ab11f899 LV |
7 | Drafted 26 August 2002 |
8 | Updated 31 January 2006 | |
1da177e4 LT |
9 | |
10 | ||
11 | Overview | |
12 | ~~~~~~~~ | |
13 | ||
ab11f899 LV |
14 | The Linux Kernel Driver Model is a unification of all the disparate driver |
15 | models that were previously used in the kernel. It is intended to augment the | |
1da177e4 LT |
16 | bus-specific drivers for bridges and devices by consolidating a set of data |
17 | and operations into globally accessible data structures. | |
18 | ||
ab11f899 LV |
19 | Traditional driver models implemented some sort of tree-like structure |
20 | (sometimes just a list) for the devices they control. There wasn't any | |
21 | uniformity across the different bus types. | |
1da177e4 | 22 | |
2e2d0dcc | 23 | The current driver model provides a common, uniform data model for describing |
ab11f899 LV |
24 | a bus and the devices that can appear under the bus. The unified bus |
25 | model includes a set of common attributes which all busses carry, and a set | |
26 | of common callbacks, such as device discovery during bus probing, bus | |
27 | shutdown, bus power management, etc. | |
1da177e4 | 28 | |
ab11f899 LV |
29 | The common device and bridge interface reflects the goals of the modern |
30 | computer: namely the ability to do seamless device "plug and play", power | |
31 | management, and hot plug. In particular, the model dictated by Intel and | |
32 | Microsoft (namely ACPI) ensures that almost every device on almost any bus | |
33 | on an x86-compatible system can work within this paradigm. Of course, | |
34 | not every bus is able to support all such operations, although most | |
5464e9c7 | 35 | buses support most of those operations. |
1da177e4 LT |
36 | |
37 | ||
38 | Downstream Access | |
39 | ~~~~~~~~~~~~~~~~~ | |
40 | ||
41 | Common data fields have been moved out of individual bus layers into a common | |
ab11f899 | 42 | data structure. These fields must still be accessed by the bus layers, |
1da177e4 LT |
43 | and sometimes by the device-specific drivers. |
44 | ||
45 | Other bus layers are encouraged to do what has been done for the PCI layer. | |
4489f161 | 46 | struct pci_dev now looks like this:: |
1da177e4 | 47 | |
4489f161 | 48 | struct pci_dev { |
1da177e4 LT |
49 | ... |
50 | ||
5464e9c7 RD |
51 | struct device dev; /* Generic device interface */ |
52 | ... | |
4489f161 | 53 | }; |
1da177e4 | 54 | |
5464e9c7 RD |
55 | Note first that the struct device dev within the struct pci_dev is |
56 | statically allocated. This means only one allocation on device discovery. | |
57 | ||
58 | Note also that that struct device dev is not necessarily defined at the | |
59 | front of the pci_dev structure. This is to make people think about what | |
60 | they're doing when switching between the bus driver and the global driver, | |
61 | and to discourage meaningless and incorrect casts between the two. | |
1da177e4 LT |
62 | |
63 | The PCI bus layer freely accesses the fields of struct device. It knows about | |
64 | the structure of struct pci_dev, and it should know the structure of struct | |
670e9f34 | 65 | device. Individual PCI device drivers that have been converted to the current |
ab11f899 | 66 | driver model generally do not and should not touch the fields of struct device, |
5464e9c7 | 67 | unless there is a compelling reason to do so. |
1da177e4 | 68 | |
5464e9c7 RD |
69 | The above abstraction prevents unnecessary pain during transitional phases. |
70 | If it were not done this way, then when a field was renamed or removed, every | |
71 | downstream driver would break. On the other hand, if only the bus layer | |
72 | (and not the device layer) accesses the struct device, it is only the bus | |
73 | layer that needs to change. | |
1da177e4 LT |
74 | |
75 | ||
76 | User Interface | |
77 | ~~~~~~~~~~~~~~ | |
78 | ||
79 | By virtue of having a complete hierarchical view of all the devices in the | |
80 | system, exporting a complete hierarchical view to userspace becomes relatively | |
81 | easy. This has been accomplished by implementing a special purpose virtual | |
5464e9c7 RD |
82 | file system named sysfs. |
83 | ||
84 | Almost all mainstream Linux distros mount this filesystem automatically; you | |
4489f161 | 85 | can see some variation of the following in the output of the "mount" command:: |
5464e9c7 | 86 | |
4489f161 MCC |
87 | $ mount |
88 | ... | |
89 | none on /sys type sysfs (rw,noexec,nosuid,nodev) | |
90 | ... | |
91 | $ | |
5464e9c7 RD |
92 | |
93 | The auto-mounting of sysfs is typically accomplished by an entry similar to | |
4489f161 | 94 | the following in the /etc/fstab file:: |
5464e9c7 | 95 | |
4489f161 | 96 | none /sys sysfs defaults 0 0 |
1da177e4 | 97 | |
4489f161 | 98 | or something similar in the /lib/init/fstab file on Debian-based systems:: |
1da177e4 | 99 | |
4489f161 | 100 | none /sys sysfs nodev,noexec,nosuid 0 0 |
1da177e4 | 101 | |
4489f161 | 102 | If sysfs is not automatically mounted, you can always do it manually with:: |
1da177e4 | 103 | |
4489f161 | 104 | # mount -t sysfs sysfs /sys |
1da177e4 LT |
105 | |
106 | Whenever a device is inserted into the tree, a directory is created for it. | |
107 | This directory may be populated at each layer of discovery - the global layer, | |
108 | the bus layer, or the device layer. | |
109 | ||
110 | The global layer currently creates two files - 'name' and 'power'. The | |
111 | former only reports the name of the device. The latter reports the | |
112 | current power state of the device. It will also be used to set the current | |
4489f161 | 113 | power state. |
1da177e4 LT |
114 | |
115 | The bus layer may also create files for the devices it finds while probing the | |
116 | bus. For example, the PCI layer currently creates 'irq' and 'resource' files | |
117 | for each PCI device. | |
118 | ||
119 | A device-specific driver may also export files in its directory to expose | |
120 | device-specific data or tunable interfaces. | |
121 | ||
122 | More information about the sysfs directory layout can be found in | |
4489f161 | 123 | the other documents in this directory and in the file |
0c1bc6b8 | 124 | Documentation/filesystems/sysfs.rst. |