aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/driver-model/overview.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/driver-model/overview.txt')
-rw-r--r--Documentation/driver-model/overview.txt114
1 files changed, 114 insertions, 0 deletions
diff --git a/Documentation/driver-model/overview.txt b/Documentation/driver-model/overview.txt
new file mode 100644
index 000000000000..44662735cf81
--- /dev/null
+++ b/Documentation/driver-model/overview.txt
@@ -0,0 +1,114 @@
1The Linux Kernel Device Model
2
3Patrick Mochel <mochel@osdl.org>
4
526 August 2002
6
7
8Overview
9~~~~~~~~
10
11This driver model is a unification of all the current, disparate driver models
12that are currently in the kernel. It is intended to augment the
13bus-specific drivers for bridges and devices by consolidating a set of data
14and operations into globally accessible data structures.
15
16Current driver models implement some sort of tree-like structure (sometimes
17just a list) for the devices they control. But, there is no linkage between
18the different bus types.
19
20A common data structure can provide this linkage with little overhead: when a
21bus driver discovers a particular device, it can insert it into the global
22tree as well as its local tree. In fact, the local tree becomes just a subset
23of the global tree.
24
25Common data fields can also be moved out of the local bus models into the
26global model. Some of the manipulations of these fields can also be
27consolidated. Most likely, manipulation functions will become a set
28of helper functions, which the bus drivers wrap around to include any
29bus-specific items.
30
31The common device and bridge interface currently reflects the goals of the
32modern PC: namely the ability to do seamless Plug and Play, power management,
33and hot plug. (The model dictated by Intel and Microsoft (read: ACPI) ensures
34us that any device in the system may fit any of these criteria.)
35
36In reality, not every bus will be able to support such operations. But, most
37buses will support a majority of those operations, and all future buses will.
38In other words, a bus that doesn't support an operation is the exception,
39instead of the other way around.
40
41
42
43Downstream Access
44~~~~~~~~~~~~~~~~~
45
46Common data fields have been moved out of individual bus layers into a common
47data structure. But, these fields must still be accessed by the bus layers,
48and sometimes by the device-specific drivers.
49
50Other bus layers are encouraged to do what has been done for the PCI layer.
51struct pci_dev now looks like this:
52
53struct pci_dev {
54 ...
55
56 struct device device;
57};
58
59Note first that it is statically allocated. This means only one allocation on
60device discovery. Note also that it is at the _end_ of struct pci_dev. This is
61to make people think about what they're doing when switching between the bus
62driver and the global driver; and to prevent against mindless casts between
63the two.
64
65The PCI bus layer freely accesses the fields of struct device. It knows about
66the structure of struct pci_dev, and it should know the structure of struct
67device. PCI devices that have been converted generally do not touch the fields
68of struct device. More precisely, device-specific drivers should not touch
69fields of struct device unless there is a strong compelling reason to do so.
70
71This abstraction is prevention of unnecessary pain during transitional phases.
72If the name of the field changes or is removed, then every downstream driver
73will break. On the other hand, if only the bus layer (and not the device
74layer) accesses struct device, it is only that layer that needs to change.
75
76
77User Interface
78~~~~~~~~~~~~~~
79
80By virtue of having a complete hierarchical view of all the devices in the
81system, exporting a complete hierarchical view to userspace becomes relatively
82easy. This has been accomplished by implementing a special purpose virtual
83file system named sysfs. It is hence possible for the user to mount the
84whole sysfs filesystem anywhere in userspace.
85
86This can be done permanently by providing the following entry into the
87/etc/fstab (under the provision that the mount point does exist, of course):
88
89none /sys sysfs defaults 0 0
90
91Or by hand on the command line:
92
93# mount -t sysfs sysfs /sys
94
95Whenever a device is inserted into the tree, a directory is created for it.
96This directory may be populated at each layer of discovery - the global layer,
97the bus layer, or the device layer.
98
99The global layer currently creates two files - 'name' and 'power'. The
100former only reports the name of the device. The latter reports the
101current power state of the device. It will also be used to set the current
102power state.
103
104The bus layer may also create files for the devices it finds while probing the
105bus. For example, the PCI layer currently creates 'irq' and 'resource' files
106for each PCI device.
107
108A device-specific driver may also export files in its directory to expose
109device-specific data or tunable interfaces.
110
111More information about the sysfs directory layout can be found in
112the other documents in this directory and in the file
113Documentation/filesystems/sysfs.txt.
114