Re: Re[2]: [Alsa-user] debuggability of ALSA

[fons a. <fon...@sk...>]

On Mon, Oct 24, 2005 at 01:52:24PM -0400, Lee Revell wrote:

> Basically you are proposing a stable kernel module ABI.  This has been
> proposed many times in the past on LKML and has always been decisively
> shot down, see the LKML archives for details.  Linus and the other
> kernel developers don't want a stable module *API*, much less an ABI.
> Among other things, it would make it WAY too easy for hardware vendors
> to insist on closed drivers.  It also would impede kernel development,
> as the kernel developers would no longer be free to add new features -
> they would have to worry about breaking binary compatibility.

There *has* to be minimal standard binary interface in order to make
modules dynamically loadable at all -- as even if the 'loader' has all
the powers of a linker, as it has, it can't look into the future and
predict which modules will ever exist. 

Having a ABI to a subset of the kernel (e.g. those parts needed by an
audio driver) would probably be beneficial. Currently, any module has
access to *all* of kernel, and there's nohting that prevents for example
an audio driver module to replace your scheduler. It's this complete
freedom ('the language is the interface') that makes it WAY to easy to
have badly written drivers that for example block interrupt handling
for a long time. A defined ABI maybe can't prevent that, but it could
at least specify that it is not done, and provide a reference against
which even closed driver code could be evaluated, and be qualified or
rejected. 

And of course, it's perfectly possible to have the completely open
module interface we have now *and* a defined ABI for some types of
modules at the same time.


-- 
FA