Question regarding minimal supported Linux kernel headers (now it is 3.2.0)

Question regarding minimal supported Linux kernel headers (now it is 3.2.0)

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

Dear Community,

Recently the patch to convert ppoll to 64 bit time has been pulled to
master branch of glibc repo.

The pselect6 conversion has been postponed on purpose as microblaze
port gained support for pselect6 from Linux kernel 3.15. Between 3.2
(minimal supported glibc Linux headers) and 3.15 this syscall is
emulated and hence the generic code is convoluted.

For the above reason the conversion of pselect6 has been postponed until
the minimal glibc's Linux headers are bumped to the version after 3.15.

Dear community - when the minimal glibc version may be increased?

Are there any guidelines when the minimal version shall be increased
(like once per X glibc releases) ?

Thanks in advance for your help.

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Question regarding minimal supported Linux kernel headers (now it is 3.2.0)

[Joseph Myers]

On Tue, 12 Nov 2019, Lukasz Majewski wrote:

> The pselect6 conversion has been postponed on purpose as microblaze
> port gained support for pselect6 from Linux kernel 3.15. Between 3.2
> (minimal supported glibc Linux headers) and 3.15 this syscall is
> emulated and hence the generic code is convoluted.
> 
> For the above reason the conversion of pselect6 has been postponed until
> the minimal glibc's Linux headers are bumped to the version after 3.15.
> 
> Dear community - when the minimal glibc version may be increased?
> 
> Are there any guidelines when the minimal version shall be increased
> (like once per X glibc releases) ?

Typically we increase the minimum kernel version used at runtime (which is 
generally the same as the minimum kernel headers version), to the oldest 
currently supported LTS Linux kernel version as listed at 
<https://www.kernel.org/category/releases.html>, when this allows some 
significant cleanup in glibc.

I think the next increase that is likely to allow significant cleanup is 
moving to 4.4 as minimum kernel version (once 3.16 is EOL); 3.16 doesn't 
allow much cleanup, but 4.4 allows removing most of the socketcall support 
from glibc as all architectures have most of the separate socket syscalls 
in 4.4 (a few were only added later for 32-bit SPARC in the compat syscall 
table on 64-bit kernels).

I was *also* hoping that, before the next increase to the minimum kernel 
version, we would have the changes Carlos proposed to remove the error on 
startup for a too-old kernel, so that new glibc running under an old 
kernel would only fail on actually trying to use one of the newer 
syscalls, which might be rare on x86_64, and might not occur in the case 
of container hosting systems that have backported newer syscalls to their 
older kernel.

For pselect6, I suggest a preparatory change increasing the minimum 
version for microblaze only and removing the racy emulation code from 
glibc citing bug 9813, which could then be marked as FIXED with 
appropriate milestone set once the emulation code has been completely 
removed.  (misc/pselect.c would change to an ENOSYS stub complete with 
stub_warning call.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Question regarding minimal supported Linux kernel headers (now it is 3.2.0)

[Adhemerval Zanella]

On 12/11/2019 11:13, Joseph Myers wrote:
> On Tue, 12 Nov 2019, Lukasz Majewski wrote:
> 
>> The pselect6 conversion has been postponed on purpose as microblaze
>> port gained support for pselect6 from Linux kernel 3.15. Between 3.2
>> (minimal supported glibc Linux headers) and 3.15 this syscall is
>> emulated and hence the generic code is convoluted.
>>
>> For the above reason the conversion of pselect6 has been postponed until
>> the minimal glibc's Linux headers are bumped to the version after 3.15.
>>
>> Dear community - when the minimal glibc version may be increased?
>>
>> Are there any guidelines when the minimal version shall be increased
>> (like once per X glibc releases) ?
> 
> For pselect6, I suggest a preparatory change increasing the minimum 
> version for microblaze only and removing the racy emulation code from 
> glibc citing bug 9813, which could then be marked as FIXED with 
> appropriate milestone set once the emulation code has been completely 
> removed.  (misc/pselect.c would change to an ENOSYS stub complete with 
> stub_warning call.)
> 

Another possibility, to avoid pessimization and make microblaze an outlier
regarding minimum kernel support (although I think we already have alpha
in this state) would be:

  1. Move generic pselect as microblaze linux specific implementation.

  2. Clean-up linux implementation to just use pselect6.

  3. Set generic as default ENOSYS/stub and set bug 9813 fixed.

  4. Base microblaze implementation on Linux generic and use fallback
     only if it returns ENOSYS.

  5. Remove __ASSUME_PSELECT6.

  6. Implement __pselect6_time64 as __ppoll_time64.  The microblaze will
     just call the __pselec6 redefined as another symbol and use fallback
     just if it returns ENOSYS.  The generic __pselec6 will use the usual
     path: __pselec6_time64 then __pselec6 if ENOSYS.  This is a performance
     hit on microblaze from kernel 3.2 to 3.15, but I think if pselect is
     indeed required, it is also expected that an updated kernel would be
     used.

Something like https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/pselect-time64
  

Re: Question regarding minimal supported Linux kernel headers (now it is 3.2.0)

[Joseph Myers]

On Tue, 12 Nov 2019, Adhemerval Zanella wrote:

> Another possibility, to avoid pessimization and make microblaze an outlier
> regarding minimum kernel support (although I think we already have alpha
> in this state) would be:
> 
>   1. Move generic pselect as microblaze linux specific implementation.
> 
>   2. Clean-up linux implementation to just use pselect6.
> 
>   3. Set generic as default ENOSYS/stub and set bug 9813 fixed.

I think marking that bug as fixed should mean eliminating the fallback 
implementation completely.  (That bug is already microblaze-specific given 
the kernel support on other architectures.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Question regarding minimal supported Linux kernel headers (now it is 3.2.0)

[Adhemerval Zanella]

On 12/11/2019 14:31, Joseph Myers wrote:
> On Tue, 12 Nov 2019, Adhemerval Zanella wrote:
> 
>> Another possibility, to avoid pessimization and make microblaze an outlier
>> regarding minimum kernel support (although I think we already have alpha
>> in this state) would be:
>>
>>   1. Move generic pselect as microblaze linux specific implementation.
>>
>>   2. Clean-up linux implementation to just use pselect6.
>>
>>   3. Set generic as default ENOSYS/stub and set bug 9813 fixed.
> 
> I think marking that bug as fixed should mean eliminating the fallback 
> implementation completely.  (That bug is already microblaze-specific given 
> the kernel support on other architectures.)
> 

Fair enough.