This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ABI compatibility


Mike,

(I think it would have been helpful to keep this in the same thread.
The context of my comments quite matters.)

On Thu, Apr 26, 2012 at 3:34 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Wednesday 25 April 2012 22:51:00 Michael Kerrisk (man-pages) wrote:
>> Now, I know that glibc doesn't gratuitously break the ABI
>
> do you have any examples of glibc breaking ABI ?

Offhand, I don't. The only one that springs to mind is the memmove()
case (that Roland cited, and glibc addressed). But the point of my
statement that you quoted here was to contrast with how one might
understand Roland's statements (that you didn't quote). To summarize
what I was trying to say (perhaps I wasn't saying it clearly enough):
"Roland, one could interpret what you are saying as meaning X, though
I observe in practice glibc doesn't do X". To get what I was meaning,
I think it's helpful to look at my comments in greater context in the
other thread.

> i'm pretty sure glibc takes
> a harder line than the kernel in maintaining compatibility. ?that's sort of
> the entire point of symbol versioning and that stuff is not taken lightly.
>
> API wise, it's not uncommon for bits to shift, but we're free to do so here,
> especially as standards change.
>
>> 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). One does not need to look too hard to find
some pretty strongly worded statements from Linus about the evils of
breaking userspace [1].

Cheers,

Michael

[1] Some examples:

"We care about user-space interfaces to an insane degree. We go to
extreme lengths to maintain even badly designed or unintentional
interfaces. Breaking user programs simply isn't acceptable."
LKML, 2005, http://thread.gmane.org/gmane.linux.kernel/361522/focus=361863

"Dammit, I'm continually surprised by the *idiots* out there that
don't understand that binary compatibility is one of the absolute top
priorities. The *only* reason for an OS kernel existing in the first
place is to serve user-space. The kernel has no relevance on its own."
LKML, 2012, http://thread.gmane.org/gmane.linux.kernel/1245999/focus=1264170


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]