| |||||||||||||
Stable APIStable APIPosted Oct 15, 2006 0:05 UTC (Sun) by i3839 (guest, #31386)In reply to: Stable API Nonsense nonsense by mrshiny Parent article: Quote of the week
I understand your point. I'm afraid there isn't an easy solution for the problem. The kernel devs want to move along, so don't want to keep the internal API stable. Keeping both the old and new API alive at the same time is problematic too, that may be harder to get right than making the new one bugfree. Having a dev branch and a stable branch of the kernel won't solve your problems either, and that's not what you asked for anyway.
What is your main grudge, that you need to upgrade the whole kernel for new drivers, or that keeping out-of-tree drivers up to date is hard? Probably both, and a stable API would solve both, no wonder you'd like it. ;-)
Would the following solution suit you: A stable kernel version where only bugfixes and new drivers or contained functionality are added, and nothing else.
Any other ideas?
(Log in to post comments)
Stable API Posted Oct 16, 2006 13:17 UTC (Mon) by mrshiny (subscriber, #4266) [Link] What I would like to see is a return, in part, to the approach used in the 2.2 and 2.4 kernels, where the kernel API was considered stable for the lifetime of the kernel. An API could be deprecated, indicating that it should no longer be used. After some period of time the API would be removed. Obviously this approach was not perfect but at least it allowed for out-of-tree drivers. I think it should be easier to separate the kernel from the drivers. With the current approach there is no deprecation period, and no warning to out-of-tree driver maintainers, thus making out-of-tree drivers "self-flaggelation".
Other projects are able to provide stable APIs (and sometimes ABIs as well) for long-lived releases. This problem is more complex in the kernel but I feel it should still be a design goal. However the kernel devs disagree and claim that not maintaining a stable API lets them improve the kernel faster. I think that if a stable API was seen as a requirement, like a stable user-space API is, they would just find a solution like they always do. Nobody seems concerned that user-space has to be stable for ever, while drivers may have incompatible APIs from point-release to point-release. I'm sure some middle ground could be found, where APIs could be deprecated for some time period and then removed eventually. Whether or not we need a stable branch with no new features, I can't say. I know lots of people would like to see that, but that isn't strictly necessary for a stable driver API or ABI.
Stable API Posted Oct 16, 2006 21:10 UTC (Mon) by i3839 (guest, #31386) [Link] As you say, the kernel devs don't have a stable API high on their wishlist. So instead of trying the impossible and let all of them work the way you want, it's more realistic to do the work yourself (with similar minded people), and to keep a stable API branch, one way or the other.
Personally I think it's best to just get all out of tree drivers merged into mainline, no matter how obscure the driver, as that's what most kernel devs seem to want. Also unrealistic, I know. But if they can't handle the flood, then they might change their mind.
Stable API (nonsense) Posted Oct 22, 2006 6:25 UTC (Sun) by HalfMoon (guest, #3211) [Link] Other projects are able to provide stable APIs (and sometimes ABIs as well) for long-lived releases. This problem is more complex in the kernel but I feel it should still be a design goal. However the kernel devs disagree and claim that not maintaining a stable API lets them improve the kernel faster. I think that if a stable API was seen as a requirement, like a stable user-space API is, they would just find a solution like they always do. The www.kernel.org kernel is however not a "long lived release". And the reason it isn't is specifically because that's a complex problem that few of the kernel developers are concerned with. What they're concerned with is bug fixing, user mode stability, and working on more hardware. That basically precludes the silly model you're promoting: freeze design bugs in concrete, for years, and pile workaround on top of workaround until it becomes unmaintainable. As has been said before: if you want a stable binary API, go ahead and commit to one. Yourself, and whichever friends join you. (Or perhaps I should say, whoever you can pay -- get to pay? -- you to provide one.) You're talking like someone who's never actually had to maintain a large software stack with multiple "frozen" layers of interfaces. And where many of those layers were misdesigned, and incapable of functioning well in a number of increasingly important cases ... maybe because they integrate poorly, and will always do so until the interfaces change. Speaking as someone who has been in that boat, I have no sympathy for your whining. If it really bothers you, you have the source code in hand and can try to do a better job. Once you really get into it you'll find that your whines were misplaced. Just get those drivers merged to the mainstream kernel, then they'll get evolved and updated with everything else. No worries, that way.
Stable API (nonsense) Posted Oct 22, 2006 18:24 UTC (Sun) by mrshiny (subscriber, #4266) [Link] For your information, I do develop software and have to deal with stableAPIs and ABIs. And I love how when kernel developers complain that maintaining an API is hard, and thus they don't want to do it, it's not called whining, but when I (and others) point out the harm this does to users, it's called whining.
Stable API Posted Oct 22, 2006 9:49 UTC (Sun) by Duncan (guest, #6647) [Link] > What I would like to see is a return, in part,> to the approach used in the 2.2 and 2.4 kernels, > where the kernel API was considered stable for > the lifetime of the kernel.
What you want, it would seem, is the continuing stable 2.6.16.* series
I'm sorry I don't remember who it was that volunteered, partly because I
Otherwise, the feeling is that many of the mission critical folks will
Duncan
Stable API Posted Nov 1, 2006 17:47 UTC (Wed) by i3839 (guest, #31386) [Link] It was Adrian Bunk, see:
http://lkml.org/lkml/2005/12/3/55
|
|||||||||||||