| |||||||||||||
Versioned APIs in the kernel?Versioned APIs in the kernel?Posted Sep 5, 2007 20:19 UTC (Wed) by michaeljt (subscriber, #39183)Parent article: LCE: Linux, hardware vendors, and enterprise distributors
I still wonder - if the kernel had versioned APIs, with a mechanism for providing several versions in parallel in one kernel, couldn't enterprise distributions apply the energy they now put to backporting stuff into creating and maintaining such APIs, and regression testing them to make sure old modules continued to work? Then they could update to more recent kernels during the lifetime of a distribution, although probably never the very newest, and actually use more or less vanilla kernels rather than the things they have now. It needn't affect other users if the additional APIs were a compile-time option.
One of these months, when I finally have some free time again, I will take a look at implementing that, although I'm not very optimistic about it being accepted into the kernel...
(Log in to post comments)
Versioned APIs in the kernel? Posted Sep 5, 2007 22:22 UTC (Wed) by khim (subscriber, #9252) [Link] This model does not work: both Windows and Solaris are trying very hard to make it work - yet ServicePacks break drivers there routinely. It's because kernel developers just can not check if driver will be broken or not by this or that change unless they either have the hardware (and nobody have all possible hardware) or they have at least driver sources (and if they do have driver sources - then why not just fix it?).
Versioned APIs in the kernel? Posted Sep 6, 2007 6:43 UTC (Thu) by michaeljt (subscriber, #39183) [Link] But would that work less well than what Redhat is doing now? Massively backporting new stuff to old kernels, breaking many things in the process and trying to fix them. In this case, the people who produce the closed source drivers which they want to keep compatible can do a quick test with new kernel versions and report back to Redhat or SUSE saying what needs to be fixed. It actually makes their life easier, as they only have to test against one tree, not every enterprise kernel. And once all regressions which interest the enterprise distributor have been fixed in a given kernel version, or they have created compatiblilty APIs to solve them (and they are only interested in binary modules which have been certified against their distribution) they can add that kernel, which by now has probably had several micro-releases, to their distribution.
Versioned APIs in the kernel? Posted Sep 6, 2007 8:14 UTC (Thu) by khim (subscriber, #9252) [Link] It actually makes their life easier, as they only have to test against one tree, not every enterprise kernel. Only the guys who produce binary drivers benefit: RedHat guys will still need to backport features, mainstream developers will be forced to keep "compatibility layer" unbroken, etc. P.S. Do you really think RedHat keeps kernels bug-for-bug compatible in the life of enterprise distribution ? Then you are mistaken: it's not uncommon to require new version of binary drivers after kernel upgrade for RHEL. They only keep old version and backport features because all other components are handled in this way too...
Versioned APIs in the kernel? Posted Sep 9, 2007 17:45 UTC (Sun) by skybrian (subscriber, #365) [Link] The whole point of having a stable API that conforms to a standard is to support interoperability with other software when you *don't* have source for it. You shouldn't need to test that specific apps work. A regression test suite that shows that you conform to the standard should be enough. If an app breaks because it's not following the standard, fix the app.
This is how application API's and network protocols work. Why can't it work for device drivers?
Of course, due to the wide variety of devices and introduction of new kinds of devices, no single standard can cover everything and no standard will last more than a few years without being replaced. But it still seems feasable to define a driver API for each type of device and support it for multiple versions of the kernel, until it eventually becomes so old that it needs to be replaced. In a typical kernel release, some of the API's will change, but most should stay the same.
Versioned APIs in the kernel? Posted Sep 10, 2007 6:49 UTC (Mon) by michaeljt (subscriber, #39183) [Link] Seems reasonably feasible to me :) However it seams to be something which the kernel developers clearly do not want to have, and since it is their kernel, they take the decisions - short of someone forking the kernel.
My idea was more a mechanism through which people could - if they liked - provide compatibility APIs when the main ones changed. Something which they would then be responsible for themselves, albeit inside the kernel, and which would be an opt-in feature at compile-time. Regression testing is definitely necessary in this case, as the kernel APIs are not so clearly defined that you can tell without testing whether something has changed or not. And the suite is whatever you wish to support.
No, I do not like the common FOSS idea that "the source code is the specification" either, at least not for anything approaching public interfaces, as it makes it much more difficult to write clean code, and much more code ends up being of the "works for me" kind. But as I said, it is not my decision, and I recognise that the work the kernel maintainers do gives them (and the people who pay them :) ) the right to lay down the rules.
Versioned APIs in the kernel? Posted Sep 22, 2007 7:09 UTC (Sat) by HalfMoon (guest, #3211) [Link] A regression test suite that shows that you conform to the standard should be enough. If an app breaks because it's not following the standard, fix the app. ... This is how application API's and network protocols work. Why can't it work for device drivers? You seem to assume that kernel developers are *gratuitously* breaking driver interfaces. Not true! In fact, the deep assumption you're making -- the unreasonable one -- is that a rock solid definition of the "standard" is possible, and reasonable. Neither is true. Have you ever tried to come up with such a definition? I've worked on several. Let me assure you, it's harder than actually implementing the code that purports to meet such specs. Several times harder. Doing a good job means considering lots of implementation strategies, and ensuring that many of them are possible. And it also involves making tradeoffs, and noticing that certain things "must" be left unspecified unless you want to rule out important implementation strategies (or spend time implementing several of them and documenting the results). And writing a test suite ... talk about hard and un-glamorous. If it's good enough to be worth using (i.e. strong coverage of the whole interface, with both positive and negative tests, shaking out timing bugs and races, etc) then it must have beeen written by a *GOOD* developer. Even just fair-to-middling developers aren't much help there. There really aren't many people who can do that kind of work, AND write. Linux may be very lucky if it's got two engineers who can do that in a given area. Taking one of them off making hardware work better, and putting them onto less rewarding spec and testsuite work ... sounds like a lose all around. Software companies can sometimes do that, if they've got a surplus of good engineers. Linux does not have such luxuries. And especially with drivers ... you're almost certain to find that the interfaces need to change because of stuff hardware designers are doing, or because after you finally understand the problem well enough to have solid code, you find that your initial interfaces have serious breakage which prevents sane support for the next chunk of hardware. (Oh, and other parts of the kernel now let you do some things better...) THAT is why it can't work for device drivers. The problem really is not that simple. And developers really are not that available.
|
|||||||||||||