. .14/a>The Linux Kernel Driver Interface
. .24/a>(all of your quese="2s answered and then some)
. .34/a>i. .44/a>Greg Kroah-Hartma2 <firstname.lastname@example.org>i. .54/a>i. .64/a>This is being written to try to explain why Linux does not have a binaryi. .74/a>kernel interface, nor does it have a stable kernel interface.4.Please
. .84/a>realize that this article describes the _in kernel_ interfaces, not the
. .94/a>kernel to userspace interfaces.4.The kernel to userspace interface is
. ptioa>the one that applicae="2 programs use, the syscall interface.4.That
. 114/a>interface is _very_ stable over time, and will not break.4.I have old
. 124/a>programs that were built on a pre 0.9something kernel that se=ll work
. 134/a>just fine on the latese . 14ioa>that users and applicae="2 programmers ca2 count on being stable.
. 154/a>i. 164/a>i. 174/a>Executive Summaryi. 184/a>-----------------i. 194/a>You think you want a stable kernel interface, but you really do not, and
. 2tioa>you don't even know it.4.What you want is a stable running driver, and
. 21ioa>you get that only if your driver is in the main kernel tree.4.You also
. 224/a>get lots of other good benefits if your driver is in the main kernel
. 234/a>tree, all of which has made Linux into such a strong, stable, and mature
. 24ioa>operae=ng system which is the reason you are us=ng it in the first
. 264/a>i. 274/a>i. 284/a>Intro
. 304/a>i. 31ioa>It's only the odd person who wants to write a kernel driver that needs
. 324/a>to worry about the in-kernel interfaces chang=ng.4.For the majority of
. 33ioa>the world, they neither see this interface, nor do they care about it at
. 354/a>i. 364/a>First off, I'm not go=ng to address _any_ legal issues about closed
. 374/a>source, hidden source, binary blobs, source wrappers, or any other term
. 38ioa>that describes kernel drivers that do not have their source code
. 394/a>released under the GPL.4.Please consult a lawyer if you have any legali. 404/a>quese="2s, I'm a programmer and hence, I'm just go=ng to be describ=ngi. 41ioa>the technical issues here (not to make light of the legal issues, theyi. 424/a>are real, and you do need to be aware of them at all times.)
. 434/a>i. 44ioa>So, there are two main topics here, binary kernel interfaces and stablei. 454/a>kernel source interfaces.4.They both depend on each other, but we willi. 464/a>discuss the binary stuff first to get it out of the way.
. 474/a>i. 484/a>i. 494/a>Binary Kernel Interface
. 504/a>-----------------------i. 51ioa>Assum=ng that we had a stable kernel source interface for the kernel, ai. 524/a>binary interface would naturally happen too, right? Wrong.4.Please
. 534/a>consider the follow=ng facts about the Linux kernel:
. 54ioa> - Depend=ng on the vers="2 of the C compiler you use, different kernel
. 55ioa> data structures will contain different alignment of structures, and
. 56ioa> possibly include different funce="2s in different ways (putt=ngi. 57ioa> funce="2s inline or not.)4.The ind=vidual funce="2 organizae="2i. 58ioa> isn't that important, but the different data structure padd=ng is
. 59ioa> very important.
. 60ioa> - Depend=ng on what kernel build ope="2s you select, a wide range of
. 61ioa> different things ca2 be assumed by the kernel:
. 62ioa> - different structures ca2 contain different fields
. 63ioa> - Some funce="2s may not be implemented at all, (i.e. some locks
. 64ioa> compile away to nothing for non-SMP builds.)
. 65ioa> - Memory within the kernel ca2 be aligned in different ways,
. 66ioa> depend=ng on the build ope="2s.
. 67ioa> - Linux runs on a wide range of different processor architectures.
. 68ioa> There is no way that binary drivers from one architecture will run
. 69ioa> on another architecture properly.
. 704/a>i. 71ioa>Now a number of these issues ca2 be addressed by simply compil=ng youri. 72ioa>module for the exact specific kernel configurae="2, us=ng the sam3 exacti. 73ioa>C compiler that the kernel was built with.4.This is sufficient if youi. 74ioa>want to provide a module for a specific release vers="2 of a specifici. 75ioa>Linux distribut="2.4.But multiply that s=ngle build by the number ofi. 764/a>different Linux distribut="2s and the number of different supported
. 774/a>releases of the Linux distribut="2 and you quickly have a nightmare of
. 784/a>different build ope="2s on different releases.4.Also realize that each
. 79ioa>Linux distribut="2 release contains a number of different kernels, all
. 8tioa>tuned to different hardware typ3s (different processor typ3s and
. 814/a>different ope="2s), so for even a s=ngle release you will need to create
. 82ioa>multiple vers="2s of your module.
. 834/a>i. 84ioa>Trust me, you will go insane over time if you try to support this kind
. 85ioa>of release, I learned this the hard way a long time ago...
. 864/a>i. 874/a>i. 884/a>Stable Kernel Source Interfaces
. 904/a>i. 914/a>This is a much more "volae=le" topic if you talk to people who try toi. 924/a>keep a Linux kernel driver that is not in the main kernel tree up toi. 934/a>date over time.
. 944/a>i. 95ioa>Linux kernel development is continuous and at a rapid pace, neveri. 964/a>stopp=ng to slow dow2.4.As such, the kernel developers find bugs ini. 974/a>current interfaces, or figure out a better way to do things.4.If they doi. 98ioa>that, they then fix the current interfaces to work better.4.When they doi. 994/a>so, funce="2 nam3s may change, structures may grow or shrink, and
.1004/a>funce="2 param3ters may be reworked.4.If this happens, all of the
.1014/a>instances of where this interface is used within the kernel are fixed up
.1024/a>at the sam3 time, ensur=ng that everything continues to work properly.
.1034/a>i.104ioa>As a specific examples of this, the in-kernel USB interfaces havei.105ioa>undergone at least three different reworks over the lifetime of thisi.1064/a>subsystem.4.These reworks were done to address a number of differenti.1074/a>issues:
.108ioa> - A change from a synchronous model of data streams to an asynchronous
.109ioa> one.4.This reduced the complexity of a number of drivers and
.110ioa> increased the throughput of all USB drivers such that we are now
.111ioa> running almost all USB devices at their maximum speed possible.
.112ioa> - A change was made in the way data packets were allocated from the
.113ioa> USB core by USB drivers so that all drivers now needed to provide
.114ioa> more informae="2 to the USB core to fix a number of documented
.1164/a>i.1174/a>This is in stark contrast to a number of closed source operae=ng systems
.1184/a>which have had to maintain their older USB interfaces over time.4.This
.1194/a>provides the ability for new developers to accidentally use the old
.12tioa>interfaces and do things in improper ways, caus=ng the stability of the
.121ioa>operae=ng system to suffer.
.1234/a>In both of these instances, all developers agreed that these were
.124ioa>important changes that needed to be made, and they were made, with
.1254/a>relae=vely little pain.4.If Linux had to ensure that it will preserve a
.1264/a>stable source interface, a new interface would have been created, and
.1274/a>the older, broken one would have had to be maintained over time, leading
.1284/a>to extra work for the USB developers.4.Since all Linux USB developers doi.1294/a>their work on their own time, ask=ng programmers to do extra work for noi.1304/a>gain, for free, is not a possibility.
.1324/a>Security issues are also very important for Linux.4.When a
.133ioa>security issue is found, it is fixed in a very short amount of time.4.A
.134ioa>number of times this has caused internal kernel interfaces to be
.1354/a>reworked to prevent the s2n1