> We did have to manage it, and we had to do a fair bit of work behind the scenes to make it invisible to the users, but we succeeded at evolution.
I suspect that Linus' view on never, ever, binning old binary interfaces will mean that there will be (un)dead interfaces supported forever. My thoughts on a management plan look like:
(*) build a test suite round existing, in-use interfaces to maintain their intended functionality
(*) build a versioning API where a version-aware program can call in to use versioned interfaces
(*) attach version info to the existing APIs and handle a 'this interface is not implemented in your version of Linux' error
(*) develop a plumbing metalanguage to support disabled/legacy interface functionality via newer intefaces
(*) have all the interfaces configurable in the makefile, defaulting to enabled
(*) stop talking and show you some code
Posted Nov 15, 2012 17:15 UTC (Thu) by nix (subscriber, #2304)
[Link]
That's pointless. With memory sizes continuing to shoot up as they are, the memory overhead of maintaining old interfaces is minimal: and as long as the interfaces have no significant maintenance overhead, why not maintain them? I mean, Linux still supports uselib(), which is IIRC useless unless you're still using a.out shared libraries and libc4!
Re API (and ABI) design and maintenance
Posted Nov 19, 2012 6:44 UTC (Mon) by k3ninho (subscriber, #50375)
[Link]
This article itself supplies an example where an older interface design has caused internal plumbing designs to be less than the best. This will happen again, and will cause a kind-of scarring to the structure of the Linux Kernel. Wouldn't you like to be able to offer end-users of the Kernel a clean set of interfaces, easy to comprehend and unhindered by history's quirks?