0001 .. _stable_api_nonsense:
0002
0003 The Linux Kernel Driver Interface
0004 ==================================
0005
0006 (all of your questions answered and then some)
0007
0008 Greg Kroah-Hartman <greg@kroah.com>
0009
0010 This is being written to try to explain why Linux **does not have a binary
0011 kernel interface, nor does it have a stable kernel interface**.
0012
0013 .. note::
0014
0015 Please realize that this article describes the **in kernel** interfaces, not
0016 the kernel to userspace interfaces.
0017
0018 The kernel to userspace interface is the one that application programs use,
0019 the syscall interface. That interface is **very** stable over time, and
0020 will not break. I have old programs that were built on a pre 0.9something
0021 kernel that still work just fine on the latest 2.6 kernel release.
0022 That interface is the one that users and application programmers can count
0023 on being stable.
0024
0025
0026 Executive Summary
0027 -----------------
0028 You think you want a stable kernel interface, but you really do not, and
0029 you don't even know it. What you want is a stable running driver, and
0030 you get that only if your driver is in the main kernel tree. You also
0031 get lots of other good benefits if your driver is in the main kernel
0032 tree, all of which has made Linux into such a strong, stable, and mature
0033 operating system which is the reason you are using it in the first
0034 place.
0035
0036
0037 Intro
0038 -----
0039
0040 It's only the odd person who wants to write a kernel driver that needs
0041 to worry about the in-kernel interfaces changing. For the majority of
0042 the world, they neither see this interface, nor do they care about it at
0043 all.
0044
0045 First off, I'm not going to address **any** legal issues about closed
0046 source, hidden source, binary blobs, source wrappers, or any other term
0047 that describes kernel drivers that do not have their source code
0048 released under the GPL. Please consult a lawyer if you have any legal
0049 questions, I'm a programmer and hence, I'm just going to be describing
0050 the technical issues here (not to make light of the legal issues, they
0051 are real, and you do need to be aware of them at all times.)
0052
0053 So, there are two main topics here, binary kernel interfaces and stable
0054 kernel source interfaces. They both depend on each other, but we will
0055 discuss the binary stuff first to get it out of the way.
0056
0057
0058 Binary Kernel Interface
0059 -----------------------
0060 Assuming that we had a stable kernel source interface for the kernel, a
0061 binary interface would naturally happen too, right? Wrong. Please
0062 consider the following facts about the Linux kernel:
0063
0064 - Depending on the version of the C compiler you use, different kernel
0065 data structures will contain different alignment of structures, and
0066 possibly include different functions in different ways (putting
0067 functions inline or not.) The individual function organization
0068 isn't that important, but the different data structure padding is
0069 very important.
0070
0071 - Depending on what kernel build options you select, a wide range of
0072 different things can be assumed by the kernel:
0073
0074 - different structures can contain different fields
0075 - Some functions may not be implemented at all, (i.e. some locks
0076 compile away to nothing for non-SMP builds.)
0077 - Memory within the kernel can be aligned in different ways,
0078 depending on the build options.
0079
0080 - Linux runs on a wide range of different processor architectures.
0081 There is no way that binary drivers from one architecture will run
0082 on another architecture properly.
0083
0084 Now a number of these issues can be addressed by simply compiling your
0085 module for the exact specific kernel configuration, using the same exact
0086 C compiler that the kernel was built with. This is sufficient if you
0087 want to provide a module for a specific release version of a specific
0088 Linux distribution. But multiply that single build by the number of
0089 different Linux distributions and the number of different supported
0090 releases of the Linux distribution and you quickly have a nightmare of
0091 different build options on different releases. Also realize that each
0092 Linux distribution release contains a number of different kernels, all
0093 tuned to different hardware types (different processor types and
0094 different options), so for even a single release you will need to create
0095 multiple versions of your module.
0096
0097 Trust me, you will go insane over time if you try to support this kind
0098 of release, I learned this the hard way a long time ago...
0099
0100
0101 Stable Kernel Source Interfaces
0102 -------------------------------
0103
0104 This is a much more "volatile" topic if you talk to people who try to
0105 keep a Linux kernel driver that is not in the main kernel tree up to
0106 date over time.
0107
0108 Linux kernel development is continuous and at a rapid pace, never
0109 stopping to slow down. As such, the kernel developers find bugs in
0110 current interfaces, or figure out a better way to do things. If they do
0111 that, they then fix the current interfaces to work better. When they do
0112 so, function names may change, structures may grow or shrink, and
0113 function parameters may be reworked. If this happens, all of the
0114 instances of where this interface is used within the kernel are fixed up
0115 at the same time, ensuring that everything continues to work properly.
0116
0117 As a specific examples of this, the in-kernel USB interfaces have
0118 undergone at least three different reworks over the lifetime of this
0119 subsystem. These reworks were done to address a number of different
0120 issues:
0121
0122 - A change from a synchronous model of data streams to an asynchronous
0123 one. This reduced the complexity of a number of drivers and
0124 increased the throughput of all USB drivers such that we are now
0125 running almost all USB devices at their maximum speed possible.
0126 - A change was made in the way data packets were allocated from the
0127 USB core by USB drivers so that all drivers now needed to provide
0128 more information to the USB core to fix a number of documented
0129 deadlocks.
0130
0131 This is in stark contrast to a number of closed source operating systems
0132 which have had to maintain their older USB interfaces over time. This
0133 provides the ability for new developers to accidentally use the old
0134 interfaces and do things in improper ways, causing the stability of the
0135 operating system to suffer.
0136
0137 In both of these instances, all developers agreed that these were
0138 important changes that needed to be made, and they were made, with
0139 relatively little pain. If Linux had to ensure that it will preserve a
0140 stable source interface, a new interface would have been created, and
0141 the older, broken one would have had to be maintained over time, leading
0142 to extra work for the USB developers. Since all Linux USB developers do
0143 their work on their own time, asking programmers to do extra work for no
0144 gain, for free, is not a possibility.
0145
0146 Security issues are also very important for Linux. When a
0147 security issue is found, it is fixed in a very short amount of time. A
0148 number of times this has caused internal kernel interfaces to be
0149 reworked to prevent the security problem from occurring. When this
0150 happens, all drivers that use the interfaces were also fixed at the
0151 same time, ensuring that the security problem was fixed and could not
0152 come back at some future time accidentally. If the internal interfaces
0153 were not allowed to change, fixing this kind of security problem and
0154 insuring that it could not happen again would not be possible.
0155
0156 Kernel interfaces are cleaned up over time. If there is no one using a
0157 current interface, it is deleted. This ensures that the kernel remains
0158 as small as possible, and that all potential interfaces are tested as
0159 well as they can be (unused interfaces are pretty much impossible to
0160 test for validity.)
0161
0162
0163 What to do
0164 ----------
0165
0166 So, if you have a Linux kernel driver that is not in the main kernel
0167 tree, what are you, a developer, supposed to do? Releasing a binary
0168 driver for every different kernel version for every distribution is a
0169 nightmare, and trying to keep up with an ever changing kernel interface
0170 is also a rough job.
0171
0172 Simple, get your kernel driver into the main kernel tree (remember we are
0173 talking about drivers released under a GPL-compatible license here, if your
0174 code doesn't fall under this category, good luck, you are on your own here,
0175 you leech). If your driver is in the tree, and a kernel interface changes,
0176 it will be fixed up by the person who did the kernel change in the first
0177 place. This ensures that your driver is always buildable, and works over
0178 time, with very little effort on your part.
0179
0180 The very good side effects of having your driver in the main kernel tree
0181 are:
0182
0183 - The quality of the driver will rise as the maintenance costs (to the
0184 original developer) will decrease.
0185 - Other developers will add features to your driver.
0186 - Other people will find and fix bugs in your driver.
0187 - Other people will find tuning opportunities in your driver.
0188 - Other people will update the driver for you when external interface
0189 changes require it.
0190 - The driver automatically gets shipped in all Linux distributions
0191 without having to ask the distros to add it.
0192
0193 As Linux supports a larger number of different devices "out of the box"
0194 than any other operating system, and it supports these devices on more
0195 different processor architectures than any other operating system, this
0196 proven type of development model must be doing something right :)
0197
0198
0199
0200 ------
0201
0202 Thanks to Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder,
0203 Robert Love, and Nishanth Aravamudan for their review and comments on
0204 early drafts of this paper.
