ABI backward-compatibility is the trick... [LWN.net]

ABI backward-compatibility is the trick...

Posted Nov 30, 2010 21:02 UTC (Tue) by madscientist (subscriber, #16861)
Parent article: The kernel and the C library as a single project

The important, and difficult, thing about libc is that is HAS to be completely backward-compatible at an ABI level. Today I can take programs that were compiled against libc's shipped with distributions 10 years or more old, and run them on my up-to-date systems with no problems caused by libc. Making this work takes a lot of detailed effort in weak linkage, linker symbol versioning, multiple versions maintained, etc. etc. Alternatives such as just providing lots of versions of libc are simply not reasonable/sustainable.

Libraries that are not careful about this type of thing are a constant source of pain and torment (I'm looking at you, ssl/crypto!)

to post comments

ABI backward-compatibility is the trick...

Posted Nov 30, 2010 22:15 UTC (Tue) by lindahl (guest, #15266) [Link] (8 responses)

You mean, other than the syscalls which aren't backward compatible, e.g. sched_setaffinity changed the number of args from 3 to 2 to 3.

ABI backward-compatibility is the trick...

Posted Nov 30, 2010 22:42 UTC (Tue) by madscientist (subscriber, #16861) [Link] (7 responses)

I'm not sure what your comment is referring to. Users of libc don't care whether syscalls are backward compatible. It's up to libc to make all those changes invisible to userspace... that's what I mean by backward-compatible ABI: the ABI between libc and the users of libc, not the ABI between libc and the kernel. In fact the advantage of moving libc into the kernel is that we would NOT need to be so worried about the ABI between libc and the kernel since they were modified in sync.

Obviously if you invoke system calls directly then you have to deal with this, but that's not relevant to whether libc comes with the kernel or not.

He meant GLibC function, not syscall...

Posted Nov 30, 2010 22:56 UTC (Tue) by khim (subscriber, #9252) [Link] (3 responses)

This is good example: sched_setaffinity(2) had two arguments before 2.3.4. If you'll take the old program which uses this version - you'll be unable to compile it today. BUT! If you'll take binary of old version of program compiled with old version of GLibC - it'll run with new one just fine because today GLibC offers two interfaces of sched_setaffinity(2) and selects them automatically depending on what the calling program expects.

GLibC maintains stable ABI - and it's very good at that (documented "undefined" behavior is exception, of course). Yet it does not maintain stable API! This experience is so alien compared to what other libraries are doing that it takes some time to wrap up the mind around the concept.

ABI == important; API == not so much...

Posted Nov 30, 2010 23:21 UTC (Tue) by madscientist (subscriber, #16861) [Link]

Yes, I agree... exactly why my comments were all discussing ABI backward-compatibility. Your example of the sched_setaffinity(2) call is, as you say, a great example of my point... ensuring that a backward-compatible ABI is available involves a lot of tricky footsie-playing with the linker etc.

API compatibility is a completely different animal: if you're going to use Linux-specific APIs then I suppose you just have to fix your code if they change in the future. If you don't want to do that, restrict yourself to POSIX and other standard APIs. I don't really worry about this, to be honest.

He meant GLibC function, not syscall...

Posted Dec 1, 2010 10:57 UTC (Wed) by Yorick (guest, #19241) [Link]

As you note, the ABI stability only goes in one direction. Someone who wishes to distribute a binary that will work on systems of varying age will have to chose between:

Building his program on a system with the oldest possible libc
Linking to libc statically
Distribute the (dynamic) libc used in the build
Keeping an old build environment somewhere and be careful not to use /usr/lib, /usr/include and so on

None of these solutions are perfect. In some ways, the Unix tradition of providing a "canonical" set of include and lib files in a prominent place, /usr, and a compiler that is configured to use these files by default, makes this harder than it would on a platform where development tools are installed separately and explicitly in a user-specified location.

He meant GLibC function, not syscall...

Posted Dec 1, 2010 14:14 UTC (Wed) by paulj (subscriber, #341) [Link]

It's not alien, it's solid engineering. Further, it takes attention to detail and work to maintain ABIs, which can be boring and unsexy - which is not what a lot of evening/weekend hackers are interested in. So likely most of this work is being done by commercial distros in response to customer demand.

Further, even for the API, there are ways to offer multiple versions of those. You can categorise your APIs in various, including with levels. Applications can then *choose* to explicitly depend on certain APIs or they can choose not to and use whatever the default API is - some applications will do that through laziness or ignorance.

All boring and hard engineering work, but it's what widely deployed (in space and, especially, time) systems tend to have to acquire.

ABI backward-compatibility is the trick...

Posted Dec 1, 2010 7:32 UTC (Wed) by steven676 (subscriber, #41893) [Link] (2 responses)

> In fact the advantage of moving libc into the kernel is that we would NOT need to be so worried about the ABI between libc and the kernel since they were modified in sync.

Not unless you want to eliminate static linking and make upgrading your kernel a nightmare. (If the ABI the kernel exposes to libc isn't stable, then libc has to be updated with the kernel -- except that the kernel update isn't effective until reboot, while the libc update will be effective for newly launched programs immediately.)

Solaris has this problem, and "solves" it via a horrible hack called "deferred activation patching" -- basically bind mounting the old libraries over the new ones until reboot. (It's also why there's no static linking on Solaris >= 10.)

ABI backward-compatibility is the trick...

Posted Dec 1, 2010 14:13 UTC (Wed) by madscientist (subscriber, #16861) [Link]

This is very true, and I don't actually believe that the kernel devs would use this as an excuse to give up on their current rules regarding userspace-visible changes. It would have all sorts of evil repercussions.

On the other hand, it's pretty darn hard to link many types of programs statically even today.

ABI backward-compatibility is the trick...

Posted Dec 3, 2010 19:50 UTC (Fri) by Spudd86 (guest, #51683) [Link]

I don't think anyone was talking about letting the kernel break libc<->kernel ABI, the talk was about making new API available sooner and having new implementations of the (old) ABI in the libc sooner. Statically linked stuff would still use the old KERNEL ABI, and it would still work, but dynamically linked stuff would use then new libc which would use new kernel ABI, hopefully offering improved performance in the process.

Basically API/ABI-wise nothing changes (at least not intentionally), except the speed at which new parts become useable.

ABI backward-compatibility is the trick...

Posted Dec 3, 2010 19:43 UTC (Fri) by Spudd86 (guest, #51683) [Link]

... not if they're linked against libc5 (OK that's slightly more than 10 years ago... but still, you can't run those binaries on a modern distro)

Also the kernel developers ARE aware of this.