| |||||||||||
Improving Linux Driver Installation (O'ReillyNet)Improving Linux Driver Installation (O'ReillyNet)Posted Sep 10, 2004 21:56 UTC (Fri) by madscientist (subscriber, #16861)Parent article: Improving Linux Driver Installation (O'ReillyNet)
I posted this at oreillynet but maybe it'd be more useful here:
Maybe I missed something. Why does DoD have to download a binary driver (assuming of course that the driver is not proprietary)? Why can't it just download the source to the driver, build it on the user's system, and install it?
Obviously this won't work all the time: if the driver source is too old it might not work with a newer kernel, and some kinds of patches might break some drivers, etc. But it would solve most of the problems relating to distro-patched kernels exponentially increasing the number of binary modules that need to be kept for download, and the DoD could hide all of this from the user and if the insmod of the newly-compiled kernel failed it could report this to the user maybe with a link where they could go to report the problem and get help.
Obviously there are some assumptions here, such as the kernel build needs to support external module builds in a robust way (but I thought 2.6's kbuild did this?); distros all would need to provide at least enough infrastructure to build external modules (which is not all that much really) and a compiler (but just C, not C++/Java/etc.) on every system as part of the base install; distros should release kernels with MODVERSIONS enabled (don't they all do that already?); kernels need to ensure their numbering scheme is lexicographically rigorous so you can associate versions of the driver source with versions of the kernel and pick the most likely fit.
And of course, as mentioned above, this does not much help proprietary kernel module vendors (although if the DoD wished they could allow binary modules to be distributed through the framework on a "best effort" basis, and give the vendor's contact info if the insmod fails instead of the OSS community info). This might even give yet more incentive for vendors to provide source rather than binary.
Just some thoughts...
(Log in to post comments)
Improving Linux Driver Installation (O'ReillyNet) Posted Sep 12, 2004 19:25 UTC (Sun) by mmarq (guest, #2332) [Link] " Why does DoD have to download a binary driver (assuming of course that the driver is not proprietary)? Why can't it just download the source to the driver, build it on the user's system, and install it? "
Because a larg part of the intented audiance for DoD, i belive, is indoctrinated in so many years of plug&play and ease of installation and use (the next, next & finish BS mantra), that they belive that they know *really* something about computers, when they dont even have the slightest idea of a booting process...
They will strick furiously against Linux, if you demonstrate that they dont know nothing,...
... that is one of the reasons, i belive, there is a very chill reception of Linux from the majority of home/SOHO computer users, strongly stimulated by the thousands and thoudsands of local "White Box" suppliers that in a large proportion dont know more than the users..., Linux intimidate them, it requires knowleadge,... it brings the prospect of having to pay for a proper support..., it could kill a large proportion of "white box" of which i suspect is thriving on illegal instalations of MS Windows and Office,...
... all that if Linux happens to dominate clearly the IT world.
Improving Linux Driver Installation (O'ReillyNet) Posted Sep 13, 2004 17:18 UTC (Mon) by madscientist (subscriber, #16861) [Link] I don't follow your comment. My thought was to provide a pointy-clicky interface that would pop up a dialog saying "you need a driver; shall I get one from the Linux secure driver server?" If the user says yes, then _BEHIND THE SCENES_ it will download, unpack, compile, and attempt to insmod the driver. None of this need be visible to the user! He can watch a little progress bar, or something like that. If one of the above steps fails another dialog pops up saying "failed" with a Details button they can use to see the gory details (stdout/stderr output from the process for example). It can provide a website they can go to for more information. It can offer to send diagnostic info (kernel version, compiler version, and the transcript) to the central server, without any guarantee that anyone will look at it (just like you get with other OS's). Etc. etc.
At no time will the "intended audience" need to have their cushy existence disturbed by confusing compiler or module load error messages... unless they want to learn.
Improving Linux Driver Installation (O'ReillyNet) Posted Sep 16, 2004 12:37 UTC (Thu) by mmarq (guest, #2332) [Link] " Why can't it just download the source to the driver, build it on the user's system, and install it? "
That is precisely the point. Dont take me rude to point you to the main article on O'Reilly... have you read it, until the end ?
The problem is driver source... DoD "should" always try to download a 'binary *thing* of some kind',... because that binary module could very well be, not the ones that he are used to now in the Linux kernel, but other kind more fit to deal with device drivers...
What has always been, open source drivers from poor documentation, years of trial and error and reverse engineering methods, simple can't keep up with the ever growing complexity... i belive you agree it was easier to chose the MOBO and build a Linux PC 5 years ago with PIII and the 1st Athlon than it is now.
|
|||||||||||