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

kernel API - a little bit less bias, please

Posted May 18, 2006 19:22 UTC (Thu) by wilck (subscriber, #29844)
Parent article: The Novell Partner Linux Driver Process

I wish that LWN was a little bit less biased in the "stable module API" vs. "all drivers must be in-tree" discussion.

The LWN editor shares Greg KH's position. That's fine. But the way this opinion is expressed ("is just not in the plans", "you do the right thing ...") is not argumentative; it simply states that people who think differently are on the wrong side, end of discussion.

That is unfortunate, because I, for one, have never been convinced by Greg's arguments. In particular, most of the arguments in the part on "stable kernel source interfaces" can be shaken by realizing that e.g. for the USB module API, one could introduce a counter like #define USB_API_VERSION 123 and someone changing the USB API would simple increase that counter (well, a slightly more elaborate scheme might be necessary, you get the idea). That wouldn't strictly be a "stable API" but one that driver authors could easily adapt to.

This simple approach can hardly have escaped the highly intelligent Linux hackers' attention. Yet it is never mentioned. It appears that the developers don't want it, because a) they outright refuse to even think about backwards compatibility, and b) they want to make life tough for the despised developers of non-GPL modules - actually, for all external developers.

Greg's advice for vendors to push their code into mainline can turn out be an extremely tough ride. His praise of the "drivers-in-mainline" model ignores its disadvantages:

the kernel gets bloated with drivers that 99% of users never need,
small and exotic drivers can be easily forgotten when changes are made (it has happened that drivers didn't even compile),
driver development is slowed down by the necessity of getting changes accepted,
the mainline developers' claim to be able to maintain all drivers for every piece of hardare out there might be just a bit too big even for their giant boots.

That said, IMO Novell is targetting its own (SLES) users in the first place. Kernel updates, in particular, are a mess if external module packages are needed. AFAICS, the Novell driver process (which consists mainly of guidelines for packaging drivers in rpm's and how to distribute these rpm packages) is primarily meant as a remedy to that problem for SLES, for both GPL and non-GPL add-on drivers. If all works well, people will be able to use YOU for the kernel just like any other package, even if they need 3rd party drivers.

Novell mentions kABI in the FAQ, a concept that goes beyond a stable source-code API. That suggests that Novell actually wants to provide a stable API (or at least much less volatile than mainline) during the lifetime of SLES10. SUSE did the same for earlier SLES releases, although less explicitly, and RedHat does for RHEL as well.

I believe that Novell is on the right track. If the driver process proves to be good for other goals, as outlined in the article, great. Not to mention that if other distributors adopted the model, it would make it much easier for vendors to support Linux distributions, and would improve the driver availability for Linux in general.

(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.

kernel API - a little bit less bias, please

Posted May 19, 2006 8:19 UTC (Fri) by eru (subscriber, #2753) [Link]

I, too find the arguments against a stable source level device interface unconvincing (while I fully agree that binary ABI is not desirable). Not wanting to stabilize the device interface made lots of sense when Linux was young, but now that it is a mainstream system, with lots of people wanting to use it with lots of different devices, refusal to provide a stable API and require inclusion of all devices in the kernel tree will simply not work for much longer. The number of devices for which open-source support is desirable and possible is simply too large for that now.

Just the kernel configuration program by itself is beginning to look like an encyclopedia of computer peripherals, and despite that many devices for which an open-source driver exists are missing, or the kernel version of the driver is out-dated.

There are people who may be willing and able to create a free driver, but are not interested in updating it forever merely because the kernel interface changes: Isn't it a pointless activity when the driver works and the hardware itself has not changed? (might even be out of production, but still be useful to support for older machines).

A carefully designed source API leaves a lot of flexibility with respect to the underlying implementation and extension possibilities. Provide "operators" (which can in reality be macroes or functions), "opaque" data types whenever possible, and rules about their use. To shake out inwarranted dependencies, you could even make a point of always putting some changes to the underlying implementation at each release, so that drivers that use the abstraction correctly are OK, but misusers break - this would also weed out attempts to use the source API as a binary ABI!

Incompatible changes cannot of course be always avoided, but they should be rare, and limited to times when a major version change occurs (like 2.6 to 2.8, if it ever happens).

kernel API - a little bit less bias, please

Posted May 19, 2006 12:48 UTC (Fri) by corbet (editor, #1) [Link]

I'm sorry if you find the reporting "biased." It is true that I feel a writer's position should be clear, rather than hidden behind some sort of bogus show of neutrality. And my position, formed by years of digging through and messing with kernel code, is that trying to cast the internal ABI in cement would slow and destabilize the whole process.

BUT when I report that a stable internal ABI is "just not in the plans," I am being flat-out factual. It is not in the plans, and there is no serious discussion about changing that. How could I have expressed that better?

kernel API - a little bit less bias, please

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

I agree that a writer should state his position. Generally, I like LWN's way of discussing things.

To me, your article conveyed something like "Thy Driver Shall Be In the Tree and Shame on You Who Disagree", and I took it as a cause to dispute that statement.

I may have misinterpreted the tone of your article. I apologize if it is so.

kernel API - a little bit less bias, please

Posted May 19, 2006 21:10 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Maybe it's just because I'm familiar with this writer's style, but I did not take "you do the right thing and ..." to be advice from Jon, but rather his description of the position that the folks in control hold.

When LWN reports on a fresh controversy, it usually "argues" both sides in that same style.