Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

Hi Joseph,

On Mon, 17 Dec 2018 17:53:36 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :

> On Sun, 16 Dec 2018, Albert ARIBAUD wrote:
> 
> > Last cycle, inclusion the Y2038 patches was postponed. I would like to
> > get them in for this release. A first few of them have landed in
> > already, I can repost the remainder of the series.  
> 
> I don't think we can practically get consensus at this time of year on the 
> trickier pieces, such as stat functions (cf. Florian's proposal; if we 
> eliminate xstat, obviously the new functions with a stat64 variant using 
> 64-bit times would need to follow), functions involving futexes, or 
> anything involving new kernel interfaces.  And obviously there is 
> sufficient risk of architecture-specific issues that such changes can't go 
> in during the freeze.  For anything using new kernel interfaces, if that 
> involves introducing a dependency on new kernel headers to build glibc, 
> that would also need to wait for an actual kernel *release* with the new 
> features.  For anything involving new structure layouts, we need to be 
> especially careful about working out the best choice of layout (should the 
> stat64 variant be the same, on all architectures, as Linux uses on 
> asm-generic 64-bit systems but with the high part of nanoseconds 
> interpreted as padding, for example? - that's not something that will be 
> decided by the kernel if the expectation is to use statx syscalls 
> everywhere to get stat information with 64-bit times from the kernel).
> 
> So while I expect more changes related to more straightforward interfaces 
> can go in before 2.29, I don't think we can add _TIME_BITS support or 
> export any of the new interfaces from the shared libraries.

I agree we can't start using kernel syscalls or types when these are
not agreed upon yet.

However, we can at least keep converting as much of glibc's internals to
using 64-bit time as possible, even though it would have to convert to
and from 32-bit time at syscall boundaries.

Would such internal changes be OK for 2.29?

(and then  later, once a first official kernel release sports Y2038
syscalls, we'd do a patch series to switch glibc implementations to
using these Y2038 syscalls)

Without syscalls, Y2038 related glibc changes could go as far as
defining a 64-bit struct timespec and struct timeval (their kernel
Y2038 versions are pretty much agreed upon) and switching to using them
internally like we're switching to using __time64_t.

We could even do the same for struct itimerspec, which is basically a
double struct timespec -- there is little risk IMO that the kernel
people might get creative with this one.

Cordialement,
Albert ARIBAUD
3ADEV