| |||||||||||||
KS2010: A staging process for ABIsKS2010: A staging process for ABIsPosted Nov 2, 2010 22:23 UTC (Tue) by buck (subscriber, #55985)Parent article: KS2010: A staging process for ABIs
One way to ease the pain of ABIs might be to insist that an ABI have
an API that lives in userland that client code could depend on not changing and have whoever sponsors the ABI inclusion commit to main- taining the API and making sure it works across kernel versions, no matter the ABI stability. At worst, if the commitment is broken, the API can be fixed by some responsible user and everybody dependent on the feature would benefit. And changes to the API could even be countenanced apart from the kernel, by the concerned community, re- gardless of how stable/unstable the ABI is
Or is this just a way of introducing inefficiency, complexity and
(Log in to post comments)
KS2010: A staging process for ABIs Posted Nov 3, 2010 15:06 UTC (Wed) by njs (guest, #40338) [Link]
This is what they do now, just the boundary between the compatibility interface and the real implementation lies inside the kernel, not in userspace. I'm not sure what difference it would make to move that outside -- it's still the same amount of code to be maintained, and now you introduce potential version skew issues.
|
|||||||||||||