This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What does LAV_CURRENT mean backwards compatibility of LD_AUDIT interface?
- From: Ben Woodard <woodard at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 19 Mar 2015 18:38:48 -0400 (EDT)
- Subject: Re: What does LAV_CURRENT mean backwards compatibility of LD_AUDIT interface?
- Authentication-results: sourceware.org; auth=none
- References: <54EFBC96 dot 7010608 at redhat dot com> <5507BE70 dot 4090800 at redhat dot com> <20150318215629 dot 2BA1D2C3B30 at topped-with-meat dot com> <550A1A30 dot 2020500 at redhat dot com> <20150319192738 dot D24212C3B11 at topped-with-meat dot com> <30A52510-F5CC-47EE-8E59-8843E7794102 at redhat dot com> <20150319210017 dot 1AF7D2C3B38 at topped-with-meat dot com>
I would agree and say that the implications are:
1) in the code fragment in the man page and in the example audit libraries in glibc we shouldn't just abort when the version passed into la_version() doesn't match the compiled in LAV_CURRENT. It should return the version of the audit interface that it was designed to use. Suggesting in the documentation that audit libraries simply return the version parameter that was passed into them seems ill advised.
2) at some point in the future if we have a not completely backward compatible change to the audit interface, we need to decide what to do when and if an audit library returns a version that glibc doesn't want to support anymore. However, I think that the odds of this happening before we have a successor to Linux and ELF are vanishingly unlikely.
-ben
> On Mar 19, 2015, at 2:00 PM, Roland McGrath <roland@hack.frob.com> wrote:
>
> That wording says to me that no actual binary compatibility between
> versions of the interface is required beyond the la_version interface being
> there in every version. Once la_version has returned, rtld knows what
> version of the interface that module supports and so the set of other
> symbols it looks up and the ABI for each can depend on that. A newer rtld
> is obliged to keep supporting older versions of the interface when such a
> version number is returned by a module's la_version. But that in no way
> means that a new version must be a superset of its predecessor or anything
> like that. Am I missing something?