On Wed, 25 Jan 2006, Theodoros V. Kalamatianos wrote:
On Tue, 24 Jan 2006, Bill Unruh wrote:
I simply do not have the technical knowledge to know if this is the problem
or if there are other technical problems with making modules "stable".
Certainly something about the interfaces is "stable". Alsa 1.0.x can be
compiled against kernel 2.6.y, or even 2.4.y and work. Ie, all the entry
points etc do not need changing. From that point of view the interface is
stable. But for some reason that module still needs to be compiled against
that kernel for it to work. Why? Is there a technical problem or is it a
lack of will ( as you suspect) or is it malice ( as the quote from
developers regarding their antipathy to non-sourcecode modules would seem
to indicate).
I think there quite a few reasons why a stable ABI is not desired:
1. You have to carry along old interfaces and live with bad design decisions.
This means that:
a. Lots of people spend time in maintaining the compatibility stuff instead
of writing new code and fixing bugs. Plus the code size increases and the
code paths where bugs can be found multiply.
Oh and lets not forget: To introduce a new design (say the Nth) for a
subsystem you'd still have to to modify the wrappers that provide the 1..N-2
versions of its ABI _and_ create a new wrapper for the N-1 ABI... Don't you
think this would be too much ? And keep in mind that something as simple as
adding a new element in a C struct results in an ABI change.
When the developers strive to reduce code duplication, it sounds stupid to me
to have multiple routines that do the same more or less job, just to keep a
stable ABI.
b. it is much more difficult to shake off known bad practices, since many
people won't fix their code unless it stops working.
c. a lot of drivers will communicate with each other via wrappers, unless
someone fixes them. Can you imagine the following:
Driver A -> old_function_ver_1 (wrapper) -> new_function ->
old_function_ver_2 -> driver B ?
and since sometimes the change in an interface may be much more than just a
function prototype this can lead in significant performance loss.
While this is true, it would seem that a more stable system than is now in
place could surely also be designed. Ie, a driver compiled against one of
the kernels 2.6.x-y would work on any of the others of that series.
2. There is a HUGE variety of ways a kernel can be compiled:
a. you can use a lot of different compilers: gcc-3.{2,3,4} and ICC are quite
common - and reasonable - options. Since the kernel uses every bit of the
intricacies of the available compiler to maximise performance its virtually
impossible to provide a stable ABI.
b. even in the same processor family you have different CPUs that may require
different calling conventions. For example x86 CPUs can use registers to pass
function arguments, which can lead in a significant speed-up... the kernel
has a Config option for this... the catch ? using it breaks binary modules,
unless they are compiled with the same option - AFAIK nvidia and linuxant do
not distribute such modules. And if you use a wrapper to fix the calling
convention the overhead may become too much in some cases.
Surely this could be an option for the module writer. Ie, if they really
want max performance, use all of the optimisations. If not, there is a more
stable option. (I guess you might say that is already there-- it is called
a user space driver).
c. there are people that compile their kernels with different options
(compiler flags, CPU optimisations, debugging, or even things like 4K vs 8K
stacks in x86).
d. And lets not get into the whole multi-platform thing...
Lets not since most sound cards for PCs do not run on Macs anyway.
To provide a stable ABI you would finally get something similar to the
current VERMAGIC stuff... which is probably not what you want, since you
still have to distribute multiple compilations of the same module. Or you
would have to live with significantly reduced performance for the next X
years just because you are unable to make the best of the new compilers and
CPU features.
3. Having an official stable ABI would encourage people to keep closed source
drivers - even for trivial reasons. This means that a device would only be
usable on the platforms an configurations the vendor supports. And it would
also mean that when the device reaches its end of product life you might not
be able to support it for a new kernel series - unless of course you decided
to keep the old ABI even for the new series... not even M$ does that...
I am all for open source drivers, whatever. But Linuxant for example is
there because the number of volunteers to write drivers for various
wireless cards for linux is simply not there. They do not exist. And
similarly for some of the other closed source drivers. Others are, I agree,
just the manufacturers being bloody minded, but lets not have the
developers and manufacturers enter into a "who can be more bloody minded"
contest.
Personally I'm all for open source drivers and the each-module-for-its-kernel
principle. It works and it does not hog down the development process with
Well, the question being raised is "does it work?". It comes at a cost, a
cost of Linux simply not supporting numerous devices (despite the valiant
efforts of many people) and of manufacturers refusing to support Linux.
maintaining obsolete code. Vendors can either provide open soure drivers,
work from userspace, or attempt to provide support the way they do now... End
Or not support Linux at all.
users who do not know how to compile a kernel can either ask their
distributors to add the missing drivers, or learn how to compile a kernel :-)
Or decide not to use Linux at all.
Which I regard as a shame.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
