Binary modules and derived works

Posted Dec 11, 2003 15:35 UTC (Thu) by corbet (editor, #1)
In reply to: Binary modules and derived works by kreutzm
Parent article: Binary modules and derived works

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 (guest, #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.