On Tuesday 24 January 2006 03:22, Bill Unruh wrote: > On Tue, 24 Jan 2006, Hemmann, Volker Armin wrote: > > On Tuesday 24 January 2006 02:43, Bill Unruh wrote: > >> On Tue, 24 Jan 2006, Hemmann, Volker Armin wrote: > >>> On Tuesday 24 January 2006 02:15, Sergei Steshenko wrote: > >>>> " > >>>> The Linux developers DO NOT WANT to make it possible to write closed > >>>> source drivers. Many consider it a violation of the GPL. > >>>> " > >>>> > >>>> - GPL allows to run commercial closed source programs under a > >>>> GPL'ed OS. That is, it doesn't prohibit this. > >>> > >>> no, but it prohibits you from incorporating gpl'ed code into closed > >>> source programms. > >> > >> ... > >> > >>>> Likewise, closed source drivers can be implemented as separate > >>>> processes not linked to GPL kernel an thus not violating GPL. > >>> > >>> so why has no one done it so far? > >>> > >>> The userland ABI and API has been stable the last ten years. > >>> > >>> You can take a binary, compiled on a computer using kernel 2.0.X and > >>> run it on 2.6.X > >>> > >>> You may need some glibc-wrapper, but that is not the kernels fault. > >>> > >>> So if you want to implement a driver that is completly independent from > >>> the kernel, lives in userspace, does not use GPL code in any form and > >>> is closed source, do it. Noone will hinder you in doing that. > >>> But if you are using GPL-code, you have to open it. > >> > >> ??? Noone is talking about a driver using GPL code. The question is how > >> one can have drivers which talk directly to the hardware and link into > >> the kernel. The code inside the driver need not use any GPL code. > > > > oh, and suddenly you want to link into the kernel? > > Again the code inside the driver module need not use any GPL code. Do we > agree on that? > > > I thought, we were talking about userspace? > > No, I am talking about a module. What is it about the relation of the > module to the kernel that you call that "linking" while the relation of > "userspace" program which also interacts with the kernel is not "linking" > And what is it about the "linking" that makes it not OK wrt the GPL. > > > btw, X11 was able to talk to hardware without any kernel-drivers. > > But it has to talk via the video card drivers which are kernel drivers I > would assume. > > >>> the sense of reality says them, that it is stupid to have fix internal > >>> api&abis, because they get into the way of efficient bug fixing and > >>> development. > >> > >> They also introduce bugs. > > > > and they fix them. > > Different ones. > > > Every piece of software has bugs. > > That is not a license for bad design. "Oh well, bugs will always be with > us, so we do not need to do anything to make them rarer."
no, but this is the licence for 'let us be flexible, we do not know at the moment what we might did wrong'. > > > Some yoears ago, there was a nice article in Scientific America, about > > bugs in software. > > They used a mathematical proof to show, that it is not possible to write > > bugfree non-trivial software. > > > > And because of bugs, it is important to fix them. > > And to design things so that bugs occur less frequently. Fixing bugs should > always play a distant second to proper design to make bugs unlikely. unlikely, but they are there, and they will pop up. And what if the bug is in the implementation, so you have to change the ABI? OOPS out of luck, sorry guys? > > > What do you do, when you find a bug in the 'holy' internal abi, that > > should not change? > > Add one wrapper after the other? > > I agree. That is a problem. But usually it is not the abi spec that is the > bug, but some implimentation. and that is why specs never get updated, right? *laughsevily* > There is a tradeoff. But as someone ignorant of driver development, surely > it is possible to design the system so that one both has stability and > flexibility. yep, it is the linux kernel development. Works fine. > > > You can see the unholy mess of drivers, when you try and install windows. > > > > > > I am glad, that linux is much more userfriendly. > > New graphic-card? I did not have to change anything or have to change > > one(!) line in xorg.conf. > > Ageed. you claim that the only way to accomplish this is to have an > unstable API/ABI? no, just in kernel drivers. And with inkernel drivers, you do not need a stable API/ABI problem solved, next please. > > > New sound-card? make modules modules_install and modprobe the drivers. No > > reboot, nothing. > > New mainboard? The old kernel boots perfectly, but sadly I need a > > different network driver. No problem. Make the module, modprobe it. > > > > That is easy. > > Agreed that is a great feature of Linux. > But surely the current method is not the only way of achieving this > objective. > It comes at the cost of > OK,new kernel, oops, my driver no longer works. > Load in the source code and > config for the kernel, get the source for the driver, and recompile the > module. What, you discovered you had to change one thing in the config of > the kernel-- oh, go ahead and recompile all your modules. > Why is it not possible to compile a module once for 2.6 kernels, and then > forget about it. Update the kernel? fine, just reuse the same module. > I do that every week: make oldconfig make all modules_install install. I do not have to care about modules or drivers. I did it once, the build scripts are doing that job now. The one solution for driver problems is to get the drivers into the kernel. After that it is a piece of cake. For the users. Wait, there is one exception: nvidia but the nvidia boys are pretty fast and helpfull and I have the good feeling, that they try to get away from the unholy fat binary blob they call driver. ------------------------------------------------------- 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
