On Tue, 13 Jun 2006 16:42:42 -0400 Lee Revell <[EMAIL PROTECTED]> wrote:
> I'm not going to participate in another binary driver flamewar. > Everything interesting that can be said about the issue has been said. > You're entitled to your opinion. > > On Tue, 2006-06-13 at 23:40 +0300, 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 > > > > > > > > > > > > _______________________________________________ > > > Alsa-user mailing list > > > Alsa-user@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/alsa-user > > > > > > > > > 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 ? > > > > 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 It's not about binary driver, it's about user friendliness through stable ABI. Suppose I install a deb/rpm/tgz Perl/Python/Tcl packages. The package contents are ASCII (source code in Perl/Python/Tcl), but because the language is prebuilt for my distribution, the package contents can be exactly the same (with bit accuracy) for RHEL/Madnriva/KNOPPIX/<you_name_it>. So, this IS user-friendly - the same (in bit sense) contents can be used regardless of distribution. I'm advocating stable ABI and as A consequence POSSIBLY binary only drivers (with possibly all the hell of them) because it will ultimately make life of end users and developers easier - a driver that once worked for one distribution will work for any other distribution for the same CPU architecture. That is, in my example with the latest KNOPPIX - if the driver from KNOPPIX works with KNOPPIX, then in can simply be copied into the poor guy's FC5, and it will work with FC5 - end of story. _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
