Commit | Line | Data |
---|---|---|
1da177e4 LT |
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 | |
a2765e81 | 13 | just fine on the latest 2.6 kernel release. That interface is the one |
1da177e4 LT |
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.) | |
1da177e4 LT |
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 | ||
30d07a22 | 132 | Security issues are also very important for Linux. When a |
1da177e4 LT |
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. |