Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | The Linux Kernel Device Model |
| 2 | |
Linas Vepstas | ab11f89 | 2006-02-03 03:03:38 -0800 | [diff] [blame] | 3 | Patrick Mochel <mochel@digitalimplant.org> |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 4 | |
Linas Vepstas | ab11f89 | 2006-02-03 03:03:38 -0800 | [diff] [blame] | 5 | Drafted 26 August 2002 |
| 6 | Updated 31 January 2006 |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 7 | |
| 8 | |
| 9 | Overview |
| 10 | ~~~~~~~~ |
| 11 | |
Linas Vepstas | ab11f89 | 2006-02-03 03:03:38 -0800 | [diff] [blame] | 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 |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 14 | bus-specific drivers for bridges and devices by consolidating a set of data |
| 15 | and operations into globally accessible data structures. |
| 16 | |
Linas Vepstas | ab11f89 | 2006-02-03 03:03:38 -0800 | [diff] [blame] | 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. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 20 | |
olecom@mail.ru | 2e2d0dc | 2006-06-26 19:05:40 +0200 | [diff] [blame] | 21 | The current driver model provides a common, uniform data model for describing |
Linas Vepstas | ab11f89 | 2006-02-03 03:03:38 -0800 | [diff] [blame] | 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. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 26 | |
Linas Vepstas | ab11f89 | 2006-02-03 03:03:38 -0800 | [diff] [blame] | 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 |
Robert P. J. Day | 5464e9c | 2011-05-28 09:31:39 -0400 | [diff] [blame] | 33 | buses support most of those operations. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 34 | |
| 35 | |
| 36 | Downstream Access |
| 37 | ~~~~~~~~~~~~~~~~~ |
| 38 | |
| 39 | Common data fields have been moved out of individual bus layers into a common |
Linas Vepstas | ab11f89 | 2006-02-03 03:03:38 -0800 | [diff] [blame] | 40 | data structure. These fields must still be accessed by the bus layers, |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 | |
Robert P. J. Day | 5464e9c | 2011-05-28 09:31:39 -0400 | [diff] [blame] | 49 | struct device dev; /* Generic device interface */ |
| 50 | ... |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 51 | }; |
| 52 | |
Robert P. J. Day | 5464e9c | 2011-05-28 09:31:39 -0400 | [diff] [blame] | 53 | Note first that the struct device dev within the struct pci_dev is |
| 54 | statically allocated. This means only one allocation on device discovery. |
| 55 | |
| 56 | Note also that that struct device dev is not necessarily defined at the |
| 57 | front of the pci_dev structure. This is to make people think about what |
| 58 | they're doing when switching between the bus driver and the global driver, |
| 59 | and to discourage meaningless and incorrect casts between the two. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 60 | |
| 61 | The PCI bus layer freely accesses the fields of struct device. It knows about |
| 62 | the structure of struct pci_dev, and it should know the structure of struct |
Paolo Ornati | 670e9f3 | 2006-10-03 22:57:56 +0200 | [diff] [blame] | 63 | device. Individual PCI device drivers that have been converted to the current |
Linas Vepstas | ab11f89 | 2006-02-03 03:03:38 -0800 | [diff] [blame] | 64 | driver model generally do not and should not touch the fields of struct device, |
Robert P. J. Day | 5464e9c | 2011-05-28 09:31:39 -0400 | [diff] [blame] | 65 | unless there is a compelling reason to do so. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 66 | |
Robert P. J. Day | 5464e9c | 2011-05-28 09:31:39 -0400 | [diff] [blame] | 67 | The above abstraction prevents unnecessary pain during transitional phases. |
| 68 | If it were not done this way, then when a field was renamed or removed, every |
| 69 | downstream driver would break. On the other hand, if only the bus layer |
| 70 | (and not the device layer) accesses the struct device, it is only the bus |
| 71 | layer that needs to change. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 72 | |
| 73 | |
| 74 | User Interface |
| 75 | ~~~~~~~~~~~~~~ |
| 76 | |
| 77 | By virtue of having a complete hierarchical view of all the devices in the |
| 78 | system, exporting a complete hierarchical view to userspace becomes relatively |
| 79 | easy. This has been accomplished by implementing a special purpose virtual |
Robert P. J. Day | 5464e9c | 2011-05-28 09:31:39 -0400 | [diff] [blame] | 80 | file system named sysfs. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 81 | |
Robert P. J. Day | 5464e9c | 2011-05-28 09:31:39 -0400 | [diff] [blame] | 82 | Almost all mainstream Linux distros mount this filesystem automatically; you |
| 83 | can see some variation of the following in the output of the "mount" command: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 84 | |
Robert P. J. Day | 5464e9c | 2011-05-28 09:31:39 -0400 | [diff] [blame] | 85 | $ mount |
| 86 | ... |
| 87 | none on /sys type sysfs (rw,noexec,nosuid,nodev) |
| 88 | ... |
| 89 | $ |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 90 | |
Robert P. J. Day | 5464e9c | 2011-05-28 09:31:39 -0400 | [diff] [blame] | 91 | The auto-mounting of sysfs is typically accomplished by an entry similar to |
| 92 | the following in the /etc/fstab file: |
| 93 | |
| 94 | none /sys sysfs defaults 0 0 |
| 95 | |
| 96 | or something similar in the /lib/init/fstab file on Debian-based systems: |
| 97 | |
| 98 | none /sys sysfs nodev,noexec,nosuid 0 0 |
| 99 | |
| 100 | If sysfs is not automatically mounted, you can always do it manually with: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 101 | |
| 102 | # mount -t sysfs sysfs /sys |
| 103 | |
| 104 | Whenever a device is inserted into the tree, a directory is created for it. |
| 105 | This directory may be populated at each layer of discovery - the global layer, |
| 106 | the bus layer, or the device layer. |
| 107 | |
| 108 | The global layer currently creates two files - 'name' and 'power'. The |
| 109 | former only reports the name of the device. The latter reports the |
| 110 | current power state of the device. It will also be used to set the current |
| 111 | power state. |
| 112 | |
| 113 | The bus layer may also create files for the devices it finds while probing the |
| 114 | bus. For example, the PCI layer currently creates 'irq' and 'resource' files |
| 115 | for each PCI device. |
| 116 | |
| 117 | A device-specific driver may also export files in its directory to expose |
| 118 | device-specific data or tunable interfaces. |
| 119 | |
| 120 | More information about the sysfs directory layout can be found in |
| 121 | the other documents in this directory and in the file |
| 122 | Documentation/filesystems/sysfs.txt. |
| 123 | |