Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Posted Jan 27, 2011 8:41 UTC (Thu) by bronson (subscriber, #4806)
Posted Jan 27, 2011 9:11 UTC (Thu) by zxcvbnm (guest, #71201)
Posted Jan 27, 2011 9:18 UTC (Thu) by smitty_one_each (subscriber, #28989)
Posted Jan 27, 2011 9:41 UTC (Thu) by trasz (guest, #45786)
Posted Jan 27, 2011 10:49 UTC (Thu) by xav (subscriber, #18536)
Posted Jan 27, 2011 11:05 UTC (Thu) by trasz (guest, #45786)
Posted Jan 27, 2011 16:15 UTC (Thu) by BrucePerens (guest, #2510)
Posted Jan 27, 2011 16:46 UTC (Thu) by trasz (guest, #45786)
Posted Jan 27, 2011 17:35 UTC (Thu) by BrucePerens (guest, #2510)
if you think about interfaces before implementing them, you don't need to go through all the code base fixing it later.
Can you now see the unconscious (at least I hope it was unconscious) disrespect for the kernel developers in that comment? You seem to believe that if the developers just thought about it, they'd get the ABIs right the first time and they'd never have to do it again.
Locking ABIs down means you just won't innovate that part of the system any longer, and you'll put up with what eventually turn out to be insufficient designs, as new requirements evolve, for the sake of stability.
Linux already has enough of that in the 40 year old Unix interface. One I/O context permanently glued to the process context. Asynchronous signals used where an OS event queue would make more sense. Whole-process fork. And then all of the later stuff made to work with the existing paradigm much less cleanly than would be necessary if we had the opportunity to redefine the process context.
Now, take those problems and multiply them, by spreading them across the entire kernel. That is what other OS maintainers have to cope with. It has been expensive for Sun, and it has been one of the factors that makes BSD the second fiddle.
Posted Jan 27, 2011 18:11 UTC (Thu) by trasz (guest, #45786)
Keeping API stable does _not_ mean one can't innovate - in particular, it doesn't prevent anyone from adding new interfaces, or new functionality. In the worst case, one needs to reimplement old API as a wrapper. It sometimes happens in userland, sometimes in horrible ways (errno symbol vs. threads, for example); but for kernel interfaces is seldom needed, and does not cause any "horrible problems", contrary to what "stable API nonsense" claims.
Regarding the UNIX heritage - yes, it's there, and nothing can be done about it, unfortunately. However, the whole "stable API nonsense" thing is about interfaces for kernel code, not for userland aplications.
Posted Jan 27, 2011 18:30 UTC (Thu) by BrucePerens (guest, #2510)
It's about keeping them stable for a reasonable amount of time, in a way that administrators and 3rd party developers can actually understand and adapt to.
The only reason to do this is to provide an interface for outside-of-tree kernel facilities. Which are their own mistake. Even if they are only device drivers.
Semantics like those of the BKL, to the extent that they leak into the semantics of your ABI, are an excellent example of semantics that are difficult to just handwave in a wrapper. You'd have to make a real lock that at a minimum would lock out all of its callers, which would be other ABI clients. Consider the Vint Cerf piece today. They made mistakes because they simply did not consider that IP devices would be mobile. We make the same mistakes every day. It's really nice when they aren't cast in concrete. Remember the story of the syntactic white space in makefiles and why we still have it today.
I'm also thinking of the ext4 data loss argument, and the discussion of what the implied semantics of rename should be and whether programmers should have to explicitly call fsync. Some of this stuff is really hard to keep from spreading its dirty fingers far beyond your wrapper.
Posted Jan 28, 2011 22:24 UTC (Fri) by giraffedata (subscriber, #1954)
The only reason to do this [keep a stable interface protocol] is to provide an interface for outside-of-tree kernel facilities. Which are their own mistake.
What besides the need for the stable interface protocol makes outside-of-tree kernel facilities a mistake?
Posted Jan 27, 2011 20:38 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
I don't know much about Solaris, however I did quite a lot of development on WinNT. It's almost possible to run WinNT4 drivers on Windows Vista there. However, it comes at a great price. For example, filesystem stack in Windows is routinely orders of magnitude slower than in Linux.
Posted Jan 28, 2011 9:48 UTC (Fri) by trasz (guest, #45786)
Posted Jan 28, 2011 13:01 UTC (Fri) by nix (subscriber, #2304)
Posted Jan 28, 2011 13:19 UTC (Fri) by trasz (guest, #45786)
Btw - of course there was a migration period, during which kernel warned about drivers that didn't declare themselves as MPSAFE ("Giant-free").
Posted Jan 28, 2011 4:14 UTC (Fri) by BenHutchings (subscriber, #37955)
Posted Jan 28, 2011 9:43 UTC (Fri) by trasz (guest, #45786)
Posted Jan 27, 2011 15:28 UTC (Thu) by jengelh (subscriber, #33263)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds