On Tuesday 24 January 2006 12:49, Sergei Steshenko wrote: >On Tue, 24 Jan 2006 09:37:10 -0800 (PST) > >Bill Unruh <[EMAIL PROTECTED]> wrote: >> On Tue, 24 Jan 2006, Sergei Steshenko wrote: >> > On Tue, 24 Jan 2006 12:39:06 +0000 >> > >> > James Courtier-Dutton <[EMAIL PROTECTED]> wrote: >> >> What we have with Linux is better than what you want. >> >> You install the Linux kernel, and you have support for all sound >> >> cards already there. No need to go searching the net for some >> >> driver like one has to do in Windows. >> >> If it is not already in the Linux kernel, your sound card is >> >> unlikely to work in Linux at all. >> >> If you want support or a bug fix for some particular sound card, >> >> you then have to either wait for your distro to support it. >> >> (similar to waiting for the manufacture's web site to be updated >> >> with a new driver), or alternatively, compile the kernel and alsa >> >> from sources, and get the very latest bug fixes and features. >> >> >> >> If you think about it, the Linux way is actually a lot better >> >> than the method you are describing. >> >> It might be, but it in general is not. It is not possible for the >> average user to just recompile. He almost certainly did not install >> the development stuff when he installed Linux. He probably did not >> install the kernel source when he installed linux. So, before he can >> do "make" he has to install a HUGE list of development programs and >> libraries and he has to find the kernel source and config files for >> his particular version of Linux. In the process he has to resolve a >> bunch of dependencies, by which time he is screaming. Then he can >> finally do the make, and the make install. >> >> Even on my system, I was going to install the 1.0.10 alsa, and ran >> make, only to notice that the only source I had installed was the >> 2.6.8.1 when I had months ago replaced the running kernel with >> 2.6.11, without the source. Also, sometimes I switch between >> kernels. And suddenly I have to recompile for both kernels. This is >> both a pain and is something that would drive the naive user around >> the bend. These things are easy for those of us who have done it a >> lot, and have gotten over the fear that anything we do could destroy >> the system (in part because we have the confidence that if it were >> destroyed, we could fix it). >> >> So, What is the problem with making the module--kernel interface so >> that a driver compiled for 2.6.x would run without recompilation on >> 2.6.y? Is it a philosophical position, that the linux developers >> want to ensure that this does not get done, as the quote seems to >> indicate? Or is there some deep technical reason why this is >> difficult/impossible to do? This is not an issue of closed >> source/open source. I am asking a technical question about the >> design of the module-kernel interface. >> >> > Basically, end user should not be forced to compile a driver. >> > Any honest developer should release his/her code only after sanity >> > checks, the first of them being compileability. So, after that >> > first sanity check the compiled driver already exists. > >Thanks for having the courage not to shut up. > >IMHO you are absolutely right about the philosophical position - it is > just it, the lack of desire to introduce stability through first > defining interfaces and then sticking to them. > >And, risking to attract even more awe - the side effect of the > "bazaar" part of development model. > >Regarding dependencies - you are again right. Even simpler than kernel > things require a lot of dependencies to be resolved - I am doing some > development, so I know it. > Such an attitude regarding the kernel is counter-productive in terms of the progress because it, if you want a really stable interface, means broken stuff has to be carried forward into the very hazy future. Never to be fixed because half the apps on the box will fall over if they do.
IMO the developers are 100% correct when they tell you that unless it is indeed a kernel module, then and only then is it have access to the defines, and then only to the src tree of the currently running kernel by well defined linkages. If the currently running kernel was an rpm/dpkg/whathaveyou install, precompiled, then those defines will not be available because the kernel's src tree isn't there. Such an error when you try to build your output, should only tell you to go to the system defines and grep for the one(s) you missed or miss-used. When they tell you to use system defines, they are telling you to use the "stable as long as its running this version of clib, with this version of the compiler" headers. These are much more stable than the kernel is ever going to be. If, in building something in userspace intended to be an application, and the writer uses the kernel headers just because they're there, then don't blame the kernel people for your stupidity when the next kernel breaks your golden effort, because thats exactly what it is at the end of the day, stupidity. I fail to see how hard it is for others to understand this seemingly innocent detail. They ignore it, and then come to whatever mailing list they're on ATM and raise hell because the kernel isn't stable. I'm not a developer except an occasional bash script to scratch a local itch, but I have written code on simpler systems and even I understand the differences implied. What makes this 'difference' so hard to grasp? This thread should die, painfully if need be. Jaroslav? Lee? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. ------------------------------------------------------- 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
