Modules Standard, extended to kernel code

[tytso at mit.edu]

   From: "Howell, David P" <david.p.howell at intel.com>
   Date: Tue, 12 Sep 2000 09:55:00 -0700

   I can see that this has been kicked around already, so I won't take it
   further that this response. 

   It's a reality that real applications sometimes include drivers and other 
   kernel code, which occasionally (just like APPs) have code that a vendor 
   doesn't want distributed in the public domain and so won't provide source 
   code; I can't see much of a difference in how this case should be handled 
   vs APPs, and I'm kinda confused why there would be such a distinction made 
   here. Doesn't seem realistic.

The difference is that while the kernel<->userspace interface is
relatively well defined and static (and is mandated by POSIX.1) whereas
the internal kernel interfaces are not.  

In reality, the number of applications that actually need to include
kernel code is relatively small.  They do exist, but they're definitely
in the 10% of the problem that requires 90% of the effort.

   As for the kernel driver interfaces, if a standard defined a abstraction
   layer (aka DDI/DKI) for developers concerned with portability and left 
   the driver internal interfaces and implementation to the architects, that 
   would work. 

And indeed, for those device driver authors that insist on including a
binary-only device driver, the way to solve this problem is to define a
source-level abstraction layer which can serve as a bridge between the
binary object file and the kernel source, and to make sure the bianry
object file doesn't make any references to any kernel symbols directly,
but instead makes all of its requests through the abstraction layer.

This abstraction layer will (it has to) exact a performance penalty,
which is why we don't have one in place today which is used by all
device drivers, much like the DDI/DKI.  If you look at such interfaces,
you'll generally find that they result in either a lot of glue code in
the kernel, or they seriously tie the hands of kernel developers who are
trying to optimize the kernel.  

(This sort of thing occasionally does happen in the kernel<->userspace
interface --- for example, telldir/seekdir interface is so botched that
it's the bane of any modern filesystem developer's existence.  But it
happens *all* the time with kernel interfaces.  Which is why Linus
refuses to have his hands tied by locking down a DDI/DKI for all
eternity.)

						- Ted