[RFC 00/10] y2038: nptl: futex: Provide support for futex_time64

[Lukasz Majewski]

On Fri, 17 Jul 2020 10:11:50 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Fri, Jul 17, 2020 at 9:27 AM Lukasz Majewski <lukma@denx.de> wrote:
> > >
> > > Yes, it is on my list. I am trying to handle the mess of stat
> > > functions  
> >
> > Regarding stat - it is indeed a mess - many versions of the same
> > functions for generic, LFS, and architectures (like ARM).
> > Conversion to 64 bit time support is challenging there as well.
> >
> > But as fair as I can tell - more than "code base" cleanup - the
> > raise of glibc minimal kernel supported version would help much
> > more in this situation as code for many "use cases" would be just
> > removed.
> >
> > A side remark - now the oldest LTS kernel supported is 4.4 and
> > oldest supported kernel for glibc is 3.2.
> > Maybe it is a good time to bump the minimal supported kernel for
> > glibc? 
> > > before starting on the lowlevellock-futex.h.  
> >
> > If you don't have time to do the conversion in next two weeks then
> > - I can in the meantime do a conversion for the above code snippet -
> > futex_reltimed_wait_time64() (and up to
> > pthread_mutex_{timed,clock}). This work shall be orthogonal to
> > lowlevellock-futex.h cleanup.
> >
> > What do you think?  
> 
> I don't think it makes any difference for stat: linux-3.2 and
> linux-5.0 appear to have the exact same kernel interface for
> newstat/stat64 and newfstatat/fstatat64 on all architectures, though
> there are two special cases that need to be handled:
> 
> - mips-n32 and ix86-x32 are lacking the stat64 version, so they only
>   have the non-LFS newstat/newfstatat version but not
> stat64/fstatat64. The x32 version is wide enough to support 64-bit
> offsets but uses the non-LFS name for it.
> 
> - alpha, parisc and sparc are 64-bit architecture with
> stat64/fstatat64, but they lack newstat/newfstatat.
> 
> While statx() was added in in linux-4.11, it was not enabled in ia64
> until linux-5.1 when we sanitized the syscall tables across
> architectures, so you can't rely on that until v5.1 is the minimum
> kernel for glibc, and that will still be a long time.

Yes, I was thinking about the statx availability since 4.11 - it
supports 64 bit time out of the box even on 32 bit machines, so can be
easily used to internally (i.e. in-glibc) implement stat calls for them.

Unfortunately, I've overlooked the case for ia64. Thanks for pointing
this out.

> 
> There may be other reasons to increase the minimum runtimer kernel
> level or the minimum kernel header version for glibc in the meantime.
> 
>      Arnd




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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20200717/3ff079cc/attachment-0001.sig>