kernel API - a little bit less bias, please [LWN.net]

kernel API - a little bit less bias, please

Posted May 18, 2006 21:23 UTC (Thu) by hazelsct (guest, #3659)
In reply to: kernel API - a little bit less bias, please by wilck
Parent article: The Novell Partner Linux Driver Process

"I, for one, have never been convinced by Greg's arguments [supporting in-tree drivers]."

"Kernel updates, in particular, are a mess if external module packages are needed."

So if in-tree drivers are bad, and external module packages are bad, what exactly do you propose? A set of independent drivers full of #ifdefs?

Thanks, but no thanks!

(Log in to post comments)

kernel API - a little bit less bias, please

Posted May 19, 2006 8:05 UTC (Fri) by wilck (subscriber, #29844) [Link]

I am not saying that in-tree drivers are generally "bad", just that goes too far to demand that everything must be in-tree. I expect Novell's driver process to simplify the "mess" I was talking about considerably.

What I propose is: to realize that a stable or at least predictable API (on the source code level) is not such a bad thing as some people claim it to be.

Btw, in-tree drivers are no guarantee against #if's, you just don't see them anymore. Some drivers maintained by vendors are kept portable between kernels in their private development version, and the #if's necessary for portability that are just stripped before merging the driver into the kernel tree.

If a vendor wants to keep full-featured drivers for different upstream and vendor kernel series, #if's are hard to avoid. The alternative "vanilla + patches" approach of DKMS may be more sympathetic to the in-tree camp, but it is neither easier to handle nor easier to understand.