On Tue, 13 Jun 2006, Sergei Steshenko wrote:
On Tue, 13 Jun 2006 16:05:40 -0400
Lee Revell <[EMAIL PROTECTED]> wrote:
On Tue, 2006-06-13 at 22:49 +0300, Sergei Steshenko wrote:
You are "aiming too low".
The true answers are:
1) drivers running in user space;
Agreed. This would help many things. For example it would solve the
binary only driver issue - vendors that feel the need to develop closed
drivers could do so without violating the GPL.
Of course it will probably hurt performance some.
2) stable, documented and adhered to ABI, so a driver compiled
once by anybody for i386 (the biggest common denominator for
IA31/IA64, AMD/Intel) will run as binary image with any kernel of any
IA31/IA64 distribution.
Not going to happen until 1) is solved.
Anyway I don't think either of these will help with the main problem
faving ALSA drivers today - vendors do not bother to test their hardware
with Linux or contribute patches to make it work. Some of them even
claim to support Linux like BenQ - I have heard that some peoples BenQ
laptops came with a Linux CD, but sound does not work on any BenQ laptop
due to an unsupported codec! They clearly did not even test it.
Lee
Look, there is a good reason that "kernel image", "bzImage", etc.
terms are used.
That is, TODAY kernel is loaded as a binary image.
So, I do not see any technical impossibility to make driver binary even
today, that it runs in kernel space.
Again, my point is:
if kernel as a whole (possibly with compiled into it drivers) is loaded
as binary image, why can't it be loaded part by part as multiple binary
images ?
Of course it can load that way. That is modules are. The problem is that
modules are so intimatley connected with the kernel that a module for
kernel A in general does not have the right entry points for Kernel B.
This is the price of high performance that one wants from kernel space
drivers.
One of the parts being (for example, ALSA) drivers.
Also, ATI/Nvidia do have recompilable glue code and ÿÿbinary driver proper
TODAY.
The sooner developers make binary drivers an easy possibility, the sooner
we'll see support from HW vendors.
The HW vendors should be given a chance to be able to minimally invest
into development process - if a driver once was compiled for, say, IA32
and worked, it should be possible to run it on any sufficiently new IA32
distribution without any additional effort on HW vendor's side.
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
