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


On Thu, Apr 26, 2012 at 4:48 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> 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.

(I think I understand the distinction you want to make between API and
ABI in this context. I don't disagree with it. Let's stick to ABI
then.)

>> 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.

I was not arguing that it is realistic. See below.

> 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.

I think you're missing my bigger point. Since version 2.10, has added
quite a number of nonstandard interfaces. None of them is documented
in the manual. From the userland programmer's point of view
*everything* is undefined. How can the userland programmer know what
to expect in terms of behavior, and stability of that behavior? But,
please, if you want to comment to that point, could you take it to the
other thread.

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/


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