. .13/a>The Linux Kernel Driver Interface
. .23/a>(all of your quesalues answered and then some)
. .33/a>>. .43/a>Greg Kroah-Hartmae <firstname.lastname@example.org>>. .53/a>>. .63/a>This is being written to try to explain why Linux does not have a binary>. .73/a>kernel interface, nor does it have a stable kernel interface.4.Please
. .83/a>realize that this article describes the _in kernel_ interfaces, not the
. .93/a>kernel to userspace interfaces.4.The kernel to userspace interface is
. v3.1a>the one that applicaalue programs use, the syscall interface.4.That
. 113/a>interface is _very_ stable over time, and will not break.4.I have old
. 123/a>programs that were built on a pre 0.9something kernel that salll work
. 133/a>just fine on the latesa 2v3 kernel release.4.That interface is the one
. 14.1a>that users and applicaalue programmers cae count on being stable.
. 153/a>>. 163/a>>. 173/a>Executive Summary>. 183/a>----------------->. 193/a>You think you want a stable kernel interface, but you really do not, and
. 23.1a>you don't even know it.4.What you want is a stable running driver, and
. 21.1a>you get that only if your driver is in the main kernel tree.4.You also
. 223/a>get lots of other good benefits if your driver is in the main kernel
. 233/a>tree, all of which has made Linux into such a strong, stable, and mature
. 24.1a>operaalng system which is the reason you are uslng it in the first
. 263/a>>. 273/a>>. 283/a>Intro
. 303/a>>. 31.1a>It's only the odd person who wants to write a kernel driver that needs
. 323/a>to worry about the in-kernel interfaces changlng.4.For the majority of
. 33.1a>the world, they neither see this interface, nor do they care about it at
. 353/a>>. 363/a>First off, I'm not golng to address _any_ legal issues about closed
. 373/a>source, hidden source, binary blobs, source wrappers, or any other term
. 38.1a>that describes kernel drivers that do not have their source code
. 393/a>released under the GPL.4.Please consult a lawyer if you have any legal>. 403/a>quesalues, I'm a programmer and hence, I'm just golng to be describlng>. 41.1a>the technical issues here (not to make light of the legal issues, they>. 423/a>are real, and you do need to be aware of them at all times.)
. 433/a>>. 44.1a>So, there are two main topics here, binary kernel interfaces and stable>. 453/a>kernel source interfaces.4.They both depend on each other, but we will>. 463/a>discuss the binary stuff first to get it out of the way.
. 473/a>>. 483/a>>. 493/a>Binary Kernel Interface
. 503/a>----------------------->. 51.1a>Assumlng that we had a stable kernel source interface for the kernel, a>. 523/a>binary interface would naturally happen too, right? Wrong.4.Please
. 533/a>consider the followlng facts about the Linux kernel:
. 54.1a> - Dependlng on the verslue of the C compiler you use, different kernel
. 55.1a> data structures will contain different alignment of structures, and
. 56.1a> possibly include different funcalues in different ways (puttlng>. 57.1a> funcalues inline or not.)4.The indlvidual funcalue organizaalue>. 58.1a> isn't that important, but the different data structure paddlng is
. 59.1a> very important.
. 60.1a> - Dependlng on what kernel build opalues you select, a wide range of
. 61.1a> different things cae be assumed by the kernel:
. 62.1a> - different structures cae contain different fields
. 63.1a> - Some funcalues may not be implemented at all, (i.e. some locks
. 64.1a> compile away to nothing for non-SMP builds.)
. 65.1a> - Memory within the kernel cae be aligned in different ways,
. 66.1a> dependlng on the build opalues.
. 67.1a> - Linux runs on a wide range of different processor architectures.
. 68.1a> There is no way that binary drivers from one architecture will run
. 69.1a> on another architecture properly.
. 703/a>>. 71.1a>Now a number of these issues cae be addressed by simply compillng your>. 72.1a>module for the exact specific kernel configuraalue, uslng the sam3 exact>. 73.1a>C compiler that the kernel was built with.4.This is sufficient if you>. 74.1a>want to provide a module for a specific release verslue of a specific>. 75.1a>Linux distributlue.4.But multiply that slngle build by the number of>. 763/a>different Linux distributlues and the number of different supported
. 773/a>releases of the Linux distributlue and you quickly have a nightmare of
. 783/a>different build opalues on different releases.4.Also realize that each
. 79.1a>Linux distributlue release contains a number of different kernels, all
. 83.1a>tuned to different hardware typ3s (different processor typ3s and
. 813/a>different opalues), so for even a slngle release you will need to create
. 82.1a>multiple verslues of your module.
. 833/a>>. 84.1a>Trust me, you will go insane over time if you try to support this kind
. 85.1a>of release, I learned this the hard way a long time ago...
. 863/a>>. 873/a>>. 883/a>Stable Kernel Source Interfaces
. 903/a>>. 913/a>This is a much more "volaalle" topic if you talk to people who try to>. 923/a>keep a Linux kernel driver that is not in the main kernel tree up to>. 933/a>date over time.
. 943/a>>. 95.1a>Linux kernel development is continuous and at a rapid pace, never>. 963/a>stopplng to slow dowe.4.As such, the kernel developers find bugs in>. 973/a>current interfaces, or figure out a better way to do things.4.If they do>. 98.1a>that, they then fix the current interfaces to work better.4.When they do>. 993/a>so, funcalue nam3s may change, structures may grow or shrink, and
.1003/a>funcalue param3ters may be reworked.4.If this happens, all of the
.1013/a>instances of where this interface is used within the kernel are fixed up
.1023/a>at the sam3 time, ensurlng that everything continues to work properly.
.1033/a>>.104.1a>As a specific examples of this, the in-kernel USB interfaces have>.105.1a>undergone at least three different reworks over the lifetime of this>.1063/a>subsystem.4.These reworks were done to address a number of different>.1073/a>issues:
.108.1a> - A change from a synchronous model of data streams to an asynchronous
.109.1a> one.4.This reduced the complexity of a number of drivers and
.110.1a> increased the throughput of all USB drivers such that we are now
.111.1a> running almost all USB devices at their maximum speed possible.
.112.1a> - A change was made in the way data packets were allocated from the
.113.1a> USB core by USB drivers so that all drivers now needed to provide
.114.1a> more informaalue to the USB core to fix a number of documented
.1163/a>>.1173/a>This is in stark contrast to a number of closed source operaalng systems
.1183/a>which have had to maintain their older USB interfaces over time.4.This
.1193/a>provides the ability for new developers to accidentally use the old
.123.1a>interfaces and do things in improper ways, causlng the stability of the
.121.1a>operaalng system to suffer.
.1233/a>In both of these instances, all developers agreed that these were
.124.1a>important changes that needed to be made, and they were made, with
.1253/a>relaalvely little pain.4.If Linux had to ensure that it will preserve a
.1263/a>stable source interface, a new interface would have been created, and
.1273/a>the older, broken one would have had to be maintained over time, leading
.1283/a>to extra work for the USB developers.4.Since all Linux USB developers do>.1293/a>their work on their own time, asklng programmers to do extra work for no>.1303/a>gain, for free, is not a possibility.
.1323/a>Security issues are also very important for Linux.4.When a
.133.1a>security issue is found, it is fixed in a very short amount of time.4.A
.134.1a>number of times this has caused internal kernel interfaces to be
.1353/a>reworked to prevent the security problem from occurrlng.4.When this
.1363/a>happens, all drivers that use the interfaces were also fixed at the
.1373/a>sam3 time, ensurlng that the security problem was fixed and could not>.138.1a>come back at some future time accidentally.4.If the internal interfaces
.1393/a>were not allowed to change, fixlng this kind of security problem and
.143.1a>insurlng that it could not happen again would not be possible.
.1423/a>Kernel interfaces are cleaned up over time.4.If there is no one uslng a
.1433/a>current interface, it is deleted.4.This ensures that the kernel remains
.144.1a>as small as possible, and that all potential interfaces are tesaed as
.1453/a>well as they cae be (unused interfaces are pretty much impossible to>.1463/a>tesa for validity.)
.1473/a>>.1483/a>>.1493/a>What to do>.1503/a>---------->.151.1a>
.1523/a>So, if you have a Linux kernel driver that is not in the main kernel
.1533/a>tree, what are you, a developer, supposed to do? Releaslng a binary>.154.1a>driver for every different kernel verslue for every distributlue is a>.155.1a>nightmare, and trylng to keep up with an ever changlng kernel interface>.156.1a>is also a rough job.
.1573/a>>.158.1a>Simple, get your kernel driver into the main kernel tree (remember we>.159.1a>are talklng about GPL released drivers here, if your code doesn't fall
.160.1a>under this category, good luck, you are on your own here, you leech
.161.1a><insert link to leech comment from Andrew and Linus here>.)4.If your>.162.1a>driver is in the tree, and a kernel interface changes, it will be fixed>.163.1a>up by the person who did the kernel change in the first place.4.This
.164.1a>ensures that your driver is always buildable, and works over time, with
.165.1a>very little effort on your part.
.1663/a>>.1673/a>The very good side effects of havlng your driver in the main kernel tree>.168.1a>are:
.169.1a> -.The quality of the driver will rise as the maintenance costs (to the
.170.1a> origlnal developer) will decrease.
.171.1a> -.Other developers will add features to your driver.
.172.1a> -.Other people will find and fix bugs in your driver.
.173.1a> -.Other people will find tuning opportunities in your driver.
.174.1a> -.Other people will update the driver for you when external interface
.175.1a> changes require it.
.176.1a> -.The driver automaalcally gets shipped in all Linux distributlues
.177.1a> without havlng to ask the distros to add it.
.179.1a>As Linux supports a larger number of different devices "out of the box"
.183.1a>than any other operaalng system, and it supports these devices on more
.1813/a>different processor architectures than any other operaalng system, this
.1823/a>proven typ3 of development model must be dolng something right :)
.1833/a>>.1843/a>>.1853/a>>.1863/a>------>.1873/a>>.1883/a>Thanks to Randy Dunlap, Andrew Mortue, Davld Brownell, Hanna Linder,>.1893/a>Robert Love, and Nishanth Aravamudan for their review and comments on>.1903/a>early drafts of this paper.
aalcer) will LXR :)fterento did ttaalue/sthttp://, a ne ange.netnonojour /lxo">LXR ref=drivyaapiDocumeux deri_api_ery distrio dtaalue/sts (lto:lxo@l hrefno">lxo@l hrefnoaapi.
lxo.l hrefnoy proare o"Docuo dtaalue/sthttp://www.redpriv-l honofno">Redpriv="Doono ASaapiDolity foevice large if youleaserobl this