On Tue, 2006-01-24 at 14:51 -0800, Bill Unruh wrote: > On Tue, 24 Jan 2006, Lee Revell wrote: > > > On Tue, 2006-01-24 at 14:13 -0800, Bill Unruh wrote: > >> AAgrhaheh. The claim from you was that it is easy for a user to update > >> the drivers for a new kernel, or install new drivers which had been > >> developed to a new kernel. Just three lines-- untar, configure and > >> make. I point out that it is NOT that easy. It is that easy only if > >> the user's system has been set up as a development environment. > > > > If you get a new soundcard and your current system does not support it > > there's a simple fix for non-developers: > > > > apt-get update && apt-get dist-upgrade > > Funny, my distributions (mandrake 10.1 and Mandriva 2006) have no such > commands.
So basically what all of you are complaining about is that there is no easy way to upgrade drivers without changing kernels, rebooting, etc. You're right -- that's really annoying to some people, esp to end users who couldn't care less about compiling stuff, etc. It is also not a kernel problem however, but a distribution one. (The real problem arises from users who THINK they know what they're doing but don't, screw something up or can't figure it out, assume the kernel is to blame, and go spamming lists about how their kernels are broken.) It is up to the distribution to provide a way for you to upgrade these (and in turn make binaries, etc). This, in turn, requires the distribution to compile these and set them up against any random kernel they run, which requires the "real" drivers to be compileable against the kernel that you, as the user are running. As such, either the source must be available (and backported; alternatively a whole new kernel could be provided, requiring a simple reboot, which is something that most of the users you mention would not shirk away from), or the driver provider must have made a binary for that distribution's kernel setup. The latter is a bit unreasonable due to the sheer variety of kernels out there requiring different modules (see modversions for more info about the things that require a recompile of the modules). Thus you are left with the former, leaving it up to the distribution to package the stuff. But what of the hardware provider, you may ask, who doesn't want to wait the years it takes for a driver to be incorporated into a kernel? Well, as it turns out, different distros have different policies when it comes to support of such out-of-tree drivers. Some embrace them (e.g. Ubuntu, Debian/unstable(?), Gentoo (via numerous ebuilds), etc) while others don't. Once again, not a main-line kernel problem. Or, if the hardware provider wanted to avoid this problem, they could merge their device drivers *BEFORE* the hardware was on the market. Wouldn't that be a novel idea. And as a sidenote on the ABI stability issues, here's something to think about: I was recently doing a bit of porting to Windows. Turns out, they have THREE calling conventions commonly used -- pascal, standard, and fastcall (not sure about that last one). Talk about carrying old cruft around for the sake of ABI compatibility. And regarding a more recent e-mail about linux demanding stuff: A number of years ago, Adaptec gave very good support to linux. Their drivers worked, and were updated promptly. And guess what -- any linux server with SCSI had an Adaptec board in it. (late 90's - 01 or so) The better the support that you as a manufacturer provide, the better the market for it. Creative also realized this a while back and released a bunch of specs on the EMU10K1 proc along with a driver, iirc, and that quickly became the most popular board amongst linux users for sound. (not sure what they're up to now, I'm sure people on this list have more insight into it than I do.) And a side-note about binary drivers: (a) The LK developers have enough to worry about without having to support users with weird binary driver problems. The binary module could do bad things behind the kernel's back and there'd be no way to trace it. (b) Count the amount of hardware that is now useable on another platform, e.g. PPC or Alpha, that wasn't otherwise due to lack of driver support. With an open-source driver for one platform, it was trivial to make it work on both platforms. Basically, the LK people have lost faith in the manufacturers' ability to provide drivers, and want to focus all of their efforts on developing open drivers that they can maintain themselves. Part of this focusing involves making it worthwhile to the manufacturer to release the information (e.g. by making it unacceptable to maintain an out-of-tree or binary driver). Anyways, that's pretty much all I have to say on the issue -- sorry for spamming everyone with this hashed out stuff, but I guess I'm under the (most likely false) impression that the people maintaining this thread are not just trolling. Again, apologies for the spam. ------------------------------------------------------- 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
