Binary modules and derived works [LWN.net]

Binary modules and derived works

Posted Dec 11, 2003 15:29 UTC (Thu) by kreutzm (subscriber, #4700)
Parent article: Binary modules and derived works

Looking from the user side, I don't see the advantage you imply at the end of your article. If I happen to have the wrong kernel version (e.g. 2.6/2.2) or even worse the wrong architecture (3D with nvidia on non-x86) or the module simply does not work as advertised - I am busted. I'd rather see the vendor supplying source and some precompiled modules as service than some semitechnical means to calm down the debate.

(Log in to post comments)

Binary modules and derived works

Posted Dec 11, 2003 15:35 UTC (Thu) by corbet (editor, #1) [Link]

Free drivers with source are obviously the right solution; I didn't really see any point in even mentioning that. That's the only kind of driver I'm interested in running on my systems. But there will always be code that, for whatever reason, will not be licensed that way. I don't believe I've ever said "make life easy for closed-source modules" or any such. What I am saying is that ambiguity helps nobody. It would be best if people simply knew what is, or is not, allowed.

Binary modules and derived works

Posted Dec 11, 2003 17:31 UTC (Thu) by elanthis (subscriber, #6227) [Link]

Unfortunately, with a changing API even in stable kernel series, Open Source or Free drivers are still just as much of a pain in the arse to end users.

End users don't upgrade kernels. They don't even know a kernel is. They don't *want* to know what a kernel is. They just want to slap in the new whizbang thingie they bought, load a driver, and have it work.

If it's assumed that all drivers will be distributed with a kernel, and that users of older versions of the kernel without the driver must upgrade, the system will not work for these users. But, even if the distributor of the hardware supplied drivers, it's still very, very likely the driver won't build.

Even if we toss ABI compatibility out the window, a *true* solid API is needed. One that will not change, *ever*, for 90% of driver needs. The API can of course be versioned, so that newer/better APIs can be added, but every kernel neesd to (perhaps only optionally) support the older APIs as well, to guarantee that modules released before the current kernel version can be compiled and installed.

Because these APIs would be intended for non-mainline modules, it's quite feasible to make them abstract and high-level, and thus perhaps slower, in order to make it very easy to keep them frozen solid, but let the underlying implementation change.