ABI mutation (was New kernels and old distributions) [LWN.net]

ABI mutation (was New kernels and old distributions)

Posted Aug 3, 2006 2:39 UTC (Thu) by davecb (subscriber, #1574)
Parent article: New kernels and old distributions

A million years ago I was on a project hosted at HI-Multics.ARPA, and had to learn how Multics dealt with API and ABI changes

To brutally oversimplify, one version-numbers the interfaces (well, structs, actually), and provides updaters and downdaters, so that the producer and consumer can change asynchronously with each other.

I've used this on Unix to avoid flag-days in a project that had a common main producer and a bunch of library-based back-end consumers.. The main program author (Hi, Edsel!) could change the interface and add an an adaptor function to main, and my consumers would automatically do the right thing. I could then change the consumers when I had time.

--davecb@spamcop.net

(Log in to post comments)

ABI mutation (was New kernels and old distributions)

Posted Aug 3, 2006 7:13 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

The problem with that approach (which is sorta similar to the model used by many UNIX vendors, and Microsoft) is that we end up with an ever growing mass of code that supports every old, deprecated, obsolete, and broken, struct you EVER supported.

Sure you can claim to deprecate the things and try to wean the users of each old version off. This can take some edge off the transition but you're only delaying the inevitable day when you say: all of you have to fix this!

Ideally you can make good decisions about your data structures in advance. In those cases you can add stuff to them and well written code can get an opaque data blob back, use the parts they understand and ignore the rest.

As a practical matter there are cases where doing that is just too ungainly and the old supported struct needs to be cleaned up or you go down the "ever growing mass of cruft" path.

Personally I think maintaining a corpus of "kernel coupled" user space code (a set of system level libraries; and perhaps some utilities like udev, lspci, the initramfs core, etc) is a good idea. The can be maintained by the kernel developers (or a group who forms and stays close to kernel development), shipped with the kernel, and packaged up like the kernel and its modules. Distros can then make calls (and dlopen()s) down into /lib/$(uname -r)/lib/... to ensure that they get the versions of these that are couple to the currently running kernel.

The VDSO mechanism might also be appropriate for some additional (though highly limited) purposes.

JimD

ABI mutation (was New kernels and old distributions)

Posted Aug 3, 2006 14:34 UTC (Thu) by davecb (subscriber, #1574) [Link]

I quite understand: I said I was brutally oversimplifying (;-)). Paul Stachour had an hour-long lecture on the subject, and that just touched on the easy examples, in structs and RDBMSs.

In practice, the consumer only has a finite period in which to adopt the new version of the interface, which was reportedly only two change cycles, and only incompatable changes, such as completely rewriting the structures used caused a forced change.

At that point, one was saying exactly that: all of you have to fix this! The advantage is that they didn't have to fix it on your schedule. Instead they fixed it on theirs. If they didn't want to fix it, of course, they could always go out of business (;-))

This ability to schedule disparate teams was the big value-add: you didn't have to convince everyone in the world to ship a patch next Tuesday.

Compatible changes, like adding a field to the end (normal practice), were commonly ignored by consumers who didn't use the field, but consumers who did could get it added without forcing all the other consumers to change. That was the common case, by the way: I'd ask Edsel for something for one consumer, he'd add it, my code would start using it and the other consumers wouldn't care.

Finally, I quite agree that there should be a corpus of kernel coupled sources, maintained either by the kernel community or, in the case of some hardware, by teams funded by those vendors. The latter practice is visible in the Samba team, where committed users of the software have staff working in or with the core team.

--davecb@spamcop.net