| |||||||||||||
Re API (and ABI) design and maintenanceRe API (and ABI) design and maintenancePosted Oct 26, 2012 18:31 UTC (Fri) by davecb (subscriber, #1574)In reply to: EPOLL_CTL_DISABLE, epoll, and API design by dlang Parent article: EPOLL_CTL_DISABLE, epoll, and API design
Creating new versions is one *step* in a disciplined (anal) process of evolution. It's been done continuously since the days of the mainframe, but people don't realize it's happening.
I spent three years at the (late, lamented) Sun Microsystems doing ABI stability, and ended up sensitized enough that I notice it when it happens.
An easy example was a company's linker, which needed a different data structure for a method call that it had. We added a new "record type" in tghe linker, and converted the compilers to produce only it. We supported the old format for a year, then made its use produce a warning, and a year after that, made it require a link-line option.
We got two complaints, total, about the option. Out of all our customers, only two were so very very far behind that they ran one of the old compilers. A year or two later a hardware change made those compilers produce impossibly lousy code, and the two outliers upgraded to the new compilers. Then we retired the old interface.
If we had moved any faster, we would have annoyed at least two customers. If we had moved any slower in switching the compilers over, we would have made the OS developers unhappy. The time between the first switch and the final stages of the retirement made the maintainers unhappy, but there weren't many bugs in that interface nor were there many user of it, so the time cost of maintaining it was low.
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.
Just as with humans, if you don't evolve, you might just die out. Homo habilis, anyone?
--dave
(Log in to post comments)
Re API (and ABI) design and maintenance Posted Nov 13, 2012 12:39 UTC (Tue) by k3ninho (subscriber, #50375) [Link]
> 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:
K3n.
Re API (and ABI) design and maintenance 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?
K3n.
|
|||||||||||||