kernel API - a little bit less bias, please

kernel API - a little bit less bias, please

Posted May 19, 2006 8:19 UTC (Fri) by eru (subscriber, #2753)
In reply to: kernel API - a little bit less bias, please by wilck
Parent article: The Novell Partner Linux Driver Process

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

---

(Log in to post comments)