| |||||||||||||
|
| |||||||||||||
Driver API anyone?Driver API anyone?Posted Jun 21, 2007 7:02 UTC (Thu) by skybrian (subscriber, #365)Parent article: Long-term support and backport risk
I suppose I'll be tarred and feathered for suggesting that stable device API's would go a long way towards making backporting drivers easy. If the point is to change part of the kernel while leaving the rest alone, shouldn't there be a distinct boundary between them with a clear contract? Then an "out of tree" driver can be a driver from a future kernel release.
(Log in to post comments)
Driver API anyone? Posted Jun 21, 2007 7:53 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] it would also prevent a lot of improvements by defining all these fixed API's
and a lot of the features that people want are more then just drivers anyway.
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 thislong 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)
Imagine that in SVABI_1.4, the int and pointer sizes bcome 64 bits,
New programs compiled after SVABI_1.4 came out use the new version,
This is a blatant oversimplification (Multics did it better), but
--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 anythingin 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,
--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.
|
|
||||||||||||