Re: [PATCH] linux: add support for uname26 personality

[Richard Henderson <rth at twiddle dot net>]

On 12/04/2015 06:43 AM, Aurelien Jarno wrote:
> 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.

It doesn't make a difference either way, as far as I can see.

One presumes that no matter what the 2.6.x version numbers will be increasing.
 So if the above is not updated for 5.0, it will still produce a 4.y for y
larger than ever existed in the real version 4 line.  So the 4.y produced by
the above function will still be "newer" than any hard-coded minimum.

Similarly if one works it the other way around.


r~