Root/
1 | The Linux Kernel Driver Interface |
2 | (all of your questions answered and then some) |
3 | |
4 | Greg Kroah-Hartman <greg@kroah.com> |
5 | |
6 | This is being written to try to explain why Linux does not have a binary |
7 | kernel interface, nor does it have a stable kernel interface. Please |
8 | realize that this article describes the _in kernel_ interfaces, not the |
9 | kernel to userspace interfaces. The kernel to userspace interface is |
10 | the one that application programs use, the syscall interface. That |
11 | interface is _very_ stable over time, and will not break. I have old |
12 | programs that were built on a pre 0.9something kernel that still work |
13 | just fine on the latest 2.6 kernel release. That interface is the one |
14 | that users and application programmers can count on being stable. |
15 | |
16 | |
17 | Executive Summary |
18 | ----------------- |
19 | You think you want a stable kernel interface, but you really do not, and |
20 | you don't even know it. What you want is a stable running driver, and |
21 | you get that only if your driver is in the main kernel tree. You also |
22 | get lots of other good benefits if your driver is in the main kernel |
23 | tree, all of which has made Linux into such a strong, stable, and mature |
24 | operating system which is the reason you are using it in the first |
25 | place. |
26 | |
27 | |
28 | Intro |
29 | ----- |
30 | |
31 | It's only the odd person who wants to write a kernel driver that needs |
32 | to worry about the in-kernel interfaces changing. For the majority of |
33 | the world, they neither see this interface, nor do they care about it at |
34 | all. |
35 | |
36 | First off, I'm not going to address _any_ legal issues about closed |
37 | source, hidden source, binary blobs, source wrappers, or any other term |
38 | that describes kernel drivers that do not have their source code |
39 | released under the GPL. Please consult a lawyer if you have any legal |
40 | questions, I'm a programmer and hence, I'm just going to be describing |
41 | the technical issues here (not to make light of the legal issues, they |
42 | are real, and you do need to be aware of them at all times.) |
43 | |
44 | So, there are two main topics here, binary kernel interfaces and stable |
45 | kernel source interfaces. They both depend on each other, but we will |
46 | discuss the binary stuff first to get it out of the way. |
47 | |
48 | |
49 | Binary Kernel Interface |
50 | ----------------------- |
51 | Assuming that we had a stable kernel source interface for the kernel, a |
52 | binary interface would naturally happen too, right? Wrong. Please |
53 | consider the following facts about the Linux kernel: |
54 | - Depending on the version of the C compiler you use, different kernel |
55 | data structures will contain different alignment of structures, and |
56 | possibly include different functions in different ways (putting |
57 | functions inline or not.) The individual function organization |
58 | isn't that important, but the different data structure padding is |
59 | very important. |
60 | - Depending on what kernel build options you select, a wide range of |
61 | different things can be assumed by the kernel: |
62 | - different structures can contain different fields |
63 | - Some functions may not be implemented at all, (i.e. some locks |
64 | compile away to nothing for non-SMP builds.) |
65 | - Memory within the kernel can be aligned in different ways, |
66 | depending on the build options. |
67 | - Linux runs on a wide range of different processor architectures. |
68 | There is no way that binary drivers from one architecture will run |
69 | on another architecture properly. |
70 | |
71 | Now a number of these issues can be addressed by simply compiling your |
72 | module for the exact specific kernel configuration, using the same exact |
73 | C compiler that the kernel was built with. This is sufficient if you |
74 | want to provide a module for a specific release version of a specific |
75 | Linux distribution. But multiply that single build by the number of |
76 | different Linux distributions and the number of different supported |
77 | releases of the Linux distribution and you quickly have a nightmare of |
78 | different build options on different releases. Also realize that each |
79 | Linux distribution release contains a number of different kernels, all |
80 | tuned to different hardware types (different processor types and |
81 | different options), so for even a single release you will need to create |
82 | multiple versions of your module. |
83 | |
84 | Trust me, you will go insane over time if you try to support this kind |
85 | of release, I learned this the hard way a long time ago... |
86 | |
87 | |
88 | Stable Kernel Source Interfaces |
89 | ------------------------------- |
90 | |
91 | This is a much more "volatile" topic if you talk to people who try to |
92 | keep a Linux kernel driver that is not in the main kernel tree up to |
93 | date over time. |
94 | |
95 | Linux kernel development is continuous and at a rapid pace, never |
96 | stopping to slow down. As such, the kernel developers find bugs in |
97 | current interfaces, or figure out a better way to do things. If they do |
98 | that, they then fix the current interfaces to work better. When they do |
99 | so, function names may change, structures may grow or shrink, and |
100 | function parameters may be reworked. If this happens, all of the |
101 | instances of where this interface is used within the kernel are fixed up |
102 | at the same time, ensuring that everything continues to work properly. |
103 | |
104 | As a specific examples of this, the in-kernel USB interfaces have |
105 | undergone at least three different reworks over the lifetime of this |
106 | subsystem. These reworks were done to address a number of different |
107 | issues: |
108 | - A change from a synchronous model of data streams to an asynchronous |
109 | one. This reduced the complexity of a number of drivers and |
110 | increased the throughput of all USB drivers such that we are now |
111 | running almost all USB devices at their maximum speed possible. |
112 | - A change was made in the way data packets were allocated from the |
113 | USB core by USB drivers so that all drivers now needed to provide |
114 | more information to the USB core to fix a number of documented |
115 | deadlocks. |
116 | |
117 | This is in stark contrast to a number of closed source operating systems |
118 | which have had to maintain their older USB interfaces over time. This |
119 | provides the ability for new developers to accidentally use the old |
120 | interfaces and do things in improper ways, causing the stability of the |
121 | operating system to suffer. |
122 | |
123 | In both of these instances, all developers agreed that these were |
124 | important changes that needed to be made, and they were made, with |
125 | relatively little pain. If Linux had to ensure that it preserve a |
126 | stable source interface, a new interface would have been created, and |
127 | the older, broken one would have had to be maintained over time, leading |
128 | to extra work for the USB developers. Since all Linux USB developers do |
129 | their work on their own time, asking programmers to do extra work for no |
130 | gain, for free, is not a possibility. |
131 | |
132 | Security issues are also very important for Linux. When a |
133 | security issue is found, it is fixed in a very short amount of time. A |
134 | number of times this has caused internal kernel interfaces to be |
135 | reworked to prevent the security problem from occurring. When this |
136 | happens, all drivers that use the interfaces were also fixed at the |
137 | same time, ensuring that the security problem was fixed and could not |
138 | come back at some future time accidentally. If the internal interfaces |
139 | were not allowed to change, fixing this kind of security problem and |
140 | insuring that it could not happen again would not be possible. |
141 | |
142 | Kernel interfaces are cleaned up over time. If there is no one using a |
143 | current interface, it is deleted. This ensures that the kernel remains |
144 | as small as possible, and that all potential interfaces are tested as |
145 | well as they can be (unused interfaces are pretty much impossible to |
146 | test for validity.) |
147 | |
148 | |
149 | What to do |
150 | ---------- |
151 | |
152 | So, if you have a Linux kernel driver that is not in the main kernel |
153 | tree, what are you, a developer, supposed to do? Releasing a binary |
154 | driver for every different kernel version for every distribution is a |
155 | nightmare, and trying to keep up with an ever changing kernel interface |
156 | is also a rough job. |
157 | |
158 | Simple, get your kernel driver into the main kernel tree (remember we |
159 | are talking about GPL released drivers here, if your code doesn't fall |
160 | under this category, good luck, you are on your own here, you leech |
161 | <insert link to leech comment from Andrew and Linus here>.) If your |
162 | driver is in the tree, and a kernel interface changes, it will be fixed |
163 | up by the person who did the kernel change in the first place. This |
164 | ensures that your driver is always buildable, and works over time, with |
165 | very little effort on your part. |
166 | |
167 | The very good side effects of having your driver in the main kernel tree |
168 | are: |
169 | - The quality of the driver will rise as the maintenance costs (to the |
170 | original developer) will decrease. |
171 | - Other developers will add features to your driver. |
172 | - Other people will find and fix bugs in your driver. |
173 | - Other people will find tuning opportunities in your driver. |
174 | - Other people will update the driver for you when external interface |
175 | changes require it. |
176 | - The driver automatically gets shipped in all Linux distributions |
177 | without having to ask the distros to add it. |
178 | |
179 | As Linux supports a larger number of different devices "out of the box" |
180 | than any other operating system, and it supports these devices on more |
181 | different processor architectures than any other operating system, this |
182 | proven type of development model must be doing something right :) |
183 | |
184 | |
185 | |
186 | ------ |
187 | |
188 | Thanks to Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder, |
189 | Robert Love, and Nishanth Aravamudan for their review and comments on |
190 | early drafts of this paper. |
191 |
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