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.

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.