kernel API - a little bit less bias, please
Posted May 18, 2006 19:22 UTC (Thu) by wilck
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.
to post comments)