This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] linux: add support for uname26 personality
- From: Aurelien Jarno <aurelien at aurel32 dot net>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 4 Dec 2015 15:43:17 +0100
- Subject: Re: [PATCH] linux: add support for uname26 personality
- Authentication-results: sourceware.org; auth=none
- References: <1449098562-9513-1-git-send-email-aurelien at aurel32 dot net> <5660076E dot 6050700 at redhat dot com> <20151203203204 dot GA27386 at aurel32 dot net> <5661A173 dot 5090106 at redhat dot com>
On 2015-12-04 15:21, Florian Weimer wrote:
> On 12/03/2015 09:32 PM, Aurelien Jarno wrote:
>
> >>> +/* When the kernel is running under the uname26 personality (for programs
> >>> + that cannot handle "Linux 3.0"), it maps version 3.x to 2.6.40+x and
> >>> + 4.x to 2.6.60+x. We need to convert that back to the standard version
> >>> + numbering to be able to compare versions. */
> >>> +static int
> >>> +convert_from_uname26 (int version)
> >>> +{
> >>> + if ((version & 0xffff00) == 0x020600)
> >>> + {
> >>> + /* 2.6.40+x to 3.x */
> >>> + if ((version & 0xff) >= 60)
> >>> + version += 0x020000 - 60;
> >>> + /* 2.6.60+x to 4.x */
> >>> + else if ((version & 0xff) >= 40)
> >>> + version += 0x010000 - 40;
> >>> + }
> >>> +
> >>> + return version;
> >>> +}
> >>
> >> â this function will have to be changed again for Linux 5.0.
> >>
> >> A long-term solution would map the minimum required version hard-coded
> >> into libc to its 2.6 equivalent, and check that if the kernel reports a
> >> 2.6 version. This is solves the forward compatibility issue because the
> >> 2.6 mapping for the minimum version is known at the time glibc is compiled.
> >
> > So you mean that we should have for example two defines in our code, one
> > for the standard version and the other for the 2.6 version and that both
> > would be defined at compilation time. Correct?
>
> Essentially, yes.
>
> > That still means we need to do the conversion at compile time to be able
> > to define both values.
>
> Or you could write the inverse function convert_from_uname26 as an
> inline function or macro, and apply it to the (constant) minimum
> version. I don't have a preference in either direction.
But then this function will have to be changed again for Linux 5.0â
Which is exactly your argument against the above code.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net