||Improving Linux Driver Installation|
|Subject:||DoD: use the source, Luke!|
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...
DoD: use the source, Luke!
2004-09-10 19:42:58 Welington [View]