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.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds