Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
ABI backward-compatibility is the trick...
Posted Nov 30, 2010 22:42 UTC (Tue) by madscientist (subscriber, #16861)
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)
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)
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.
Posted Dec 1, 2010 10:57 UTC (Wed) by Yorick (subscriber, #19241)
Posted Dec 1, 2010 14:14 UTC (Wed) by paulj (subscriber, #341)
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.
Posted Dec 1, 2010 7:32 UTC (Wed) by steven676 (subscriber, #41893)
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.)
Posted Dec 1, 2010 14:13 UTC (Wed) by madscientist (subscriber, #16861)
On the other hand, it's pretty darn hard to link many types of programs statically even today.
Posted Dec 3, 2010 19:50 UTC (Fri) by Spudd86 (guest, #51683)
Basically API/ABI-wise nothing changes (at least not intentionally), except the speed at which new parts become useable.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds