On Tue, 24 Jan 2006, Bill Unruh wrote:
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.
I disagree. linux-2.6.0 was released IIRC two years ago. In the meantime
the kernel internals have changed a lot - some times because a subsystem
was redesigned, some times because a new technology (say wireless
networking or DVB TV cards) needed to be supported. So module distributors
would have to supply binary blobs for the different ABI versions even
within the same kernel series. And for drivers that use multiple
subsystems it would come down to one binary for each kernel version...
Put in this mess the fact that many distributors patch their kernels so
you think that you have 2.6.14 while it is more like a 2.6.15 but not
quite a 2.6.15 and you can imagine the confusion this would cause to both
users and developers.
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).
Well, the module writer can do whatever he wants, but the kernel
developers would still have to provide the infrastructure to do so. And in
order to provide a stable ABI with all compiler versions one would have to
forego important optimisations. Function inlining is a good example, since
a function might be a normal symbol under a certain compiler and then
disappear (i.e. become inline) for another compiler.
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.
Actually I am not sure how valid this is for PCI and USB cards... AFAIK
there is no reason the card itself would not function under another CPU
family... apart from driver support of course.
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.
Volunteers do exist, but the manufacturers refuse to release the device
specs. I think that releasing programming information for a device would
be the best for a manufacturer. They do not have to develop a driver
themselves, and their device will be eventually supported on every
OS/platform with enough motivated developers.
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.
I do not really think that a stable ABI would change this. The nvidia-like
solution (however controversial) solves the technical problems, without
requiring a stable ABI, and I severely doubt that a stable ABI would
require any less work from the manufacturer. It would only result to a
driver-less device in the long run when the old ABI is dropped.
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.
To be honest, I don't see how having a stable ABI would help vendors
develop a new driver. It might ease its _maintenance_ a bit, but I don't
think that the overhead of the rather rare API changes is that big.
I think that the reasons Linux is not supported by most vendors are more
financial than technical...it is the classic chicken-egg problem: vendors
won't support Linux unless it has users and people won't use Linux unless
it supports their devices.
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.
Let's be honest here: if a new driver does not yet exist in a
distribution, it's usually rather immature. People that are that anxious
to use immature code should be able to handle a kernel compile. If not
they should wait for their distribution to support it, rather that get a
binary blob from somewhere and then blame Linux because it crashes or
whatever.
-------------------------------------------------------
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
