ABI compatibility

[Mike Frysinger]

On Thursday 26 April 2012 00:13:10 Michael Kerrisk wrote:
> On Thu, Apr 26, 2012 at 3:34 PM, Mike Frysinger wrote:
> > On Wednesday 25 April 2012 22:51:00 Michael Kerrisk wrote:
> >> reading of your comments is that they provide a rather weaker
> >> guarantee than the statements from Linux kernel developers, where
> >> ABI/API compatibility is an oft-stated and overriding priority
> > 
> > err, no ... API compat has never been a goal in the Linux kernel.  quite
> > the opposite actually (which Documentation/stable_api_nonsense.txt is
> > unambiguous in stating).  further, ABI compatibility has basically been
> > defined as "if it breaks, and no one complains, then it's OK".  there
> > are documented cases of this happening in the last year, and Linus more
> > or less held that up at the kernel summit this last October.
> 
> That document you quote is about *internal* kernel APIs. I was talking
> about the *external* API/ABI that the kernel presents to userspace
> applications (just as I was talking about the API/ABI that glibc
> presents to userspace).

the kernel doesn't really have a userspace API.  if you consider things like 
structs or define names or headers as part of the sanitized user space headers, 
the kernel certainly feels free to change those.  to the point where they 
remove/add/rename funcs or defines or headers all the time.

> One does not need to look too hard to find
> some pretty strongly worded statements from Linus about the evils of
> breaking userspace [1].

yes, you just backed up my position.  he does not purely maintain the ABI, he 
maintains the ABI that userland actually relies on.  these are not the same 
thing.  it isn't hard to locate changes that knowingly break ABI that Linus 
merged because all known users of the interface are not affected.  here's one 
from the last release:
	http://lwn.net/Articles/483078/

similarly, glibc has latitude to operate within the bounds of "implementation 
details".  relying on undefined (either by glibc or a standard) behavior to 
never changed is not realistic.

you could make the same argument that doing free() on the same pointer that 
didn't crash with older glibcs but now does (because glibc has added more 
sanity checking to its internal state) broke the ABI.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120426/79d9eacf/attachment.sig>