Driver API anyone? [LWN.net]

Driver API anyone?

Posted Jun 21, 2007 8:38 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

I still wonder why a stable API has to be such an all or nothing thing? Is a middle ground not possible, on the lines of "we will take trouble to prevent API changes, but not at any cost"? Or to put it another way, stop and think three times before breaking the API, but if you still come to the same conclusion the third time then do it anyway.

And a more stable API would make it easier, not just to backport drivers, but also to forward-port out-of-tree drivers to new kernels, which in turn would make it easier for distributors to stick to kernel.org kernels, perhaps one or two releases behind the current one, with the current one as an option for non-critical setups.

Driver API anyone?

Posted Jun 21, 2007 13:13 UTC (Thu) by davecb (subscriber, #1574) [Link]

There is a middle ground: versioned APIs. Multics did this
long before Unix even existed, and the big commercial vendors
are doing a subset of it for kernel->userland APIs.

Assume a function setvbuf(FILE *fp, char *buf, int type, size_t size)
where the size_t is about to becomes a 64-bit variable. The user
writes a call to setvbuf and at link time it's mapped internally
to setvbuf'SYSVABI_1.3 where the SYSVABI_1.3 is only visible to
tools likle (Solaris) pvs.

Imagine that in SVABI_1.4, the int and pointer sizes bcome 64 bits,
but our program doesn't call it: it calls the 32-bit one
from SYSVABI_1.3. Updated systems have two copies of setvbuf,
one for each version, and the elf loader uses the labelled ones
to disambiguate calls from old versus new binaries.

New programs compiled after SVABI_1.4 came out use the new version,
and if a program or driver is recompiled, it uses the newest ones.

This is a blatant oversimplification (Multics did it better), but
you get the flavor...

--dave

Driver API anyone?

Posted Jun 21, 2007 21:46 UTC (Thu) by arjan (subscriber, #36785) [Link]

this sounds easy...

but once you need to include locking rules (as any in-kernel API has).. it gets a HECK of a lot more tricky. You end up with a WAAY too bloated kernel, or you get translations layers...

Driver API anyone?

Posted Jun 22, 2007 7:19 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

Something like that could work (at least, I imagine it could :) ) if the API/ABI numbers applied to subsystems (e.g. the wireless extensions) and not to single functions. You would need at least two version numbers - the current one and the last one with which the current is backwards compatible. It would probably be more of an "ease the transistion pain" measure though, as I can't see the kernel developers being happy to keep maintaining older APIs once they started needing too much code of their own.

Driver API anyone?

Posted Jun 22, 2007 14:28 UTC (Fri) by davecb (subscriber, #1574) [Link]

In practice, we only maintained one older version for anything
in development, but froze anything we gave to end-user customers.
Since this is a **kernel** api we're talking about, I wouldn't
keep more tan one "old" version.

The Multicians never seemed to get more than one old version,
but that assumed a very active support process to keep all
the customer machines sufficiently current.

--dave

Driver API anyone?

Posted Jun 22, 2007 7:27 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

Versioned APIs/ABIs could help here where changes are unavoidable, but I think that the main problem here - at least from the point of view of those who write out-of-tree kernel extensions - is that many kernel developers do not consider the kernel APIs to be a stable external APIs at all, preferring instead that external drivers and subsystems be brought into the kernel at the earliest possible point in time. I think that they do not make too much effort to keep the interfaces stable because they do not really consider them to be interfaces.