This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof
On Fri, 8 Sep 2017 17:59:00 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :
> On Fri, 8 Sep 2017, Albert ARIBAUD wrote:
>
> > Regarding whether the patches should land only once the kernel is
> > Y0238-safe: these patches are intended to run even on a current and thus
> > completely Y2038-unsafe kernel, in which case they use 64-bit-time on
> > user side (to make applications compiled with _TIME_BITS==64 happy at
> > least until Y2038 happens) and 32-bit time on kernel side. So I don't
> > see why these patches should wait for a Y2038-safe kernel per se.
>
> Where the kernel layouts of structures are suitable for use by glibc, we'd
> like to avoid translation layers. E.g., we need to know what the kernel's
> struct stat64 variant for 64-bit time_t will look like to ensure no
> translation layer is needed. (If the answer is that statx is the
> interface that should be used for 64-bit times in struct stat so the
> kernel doesn't need to define such a stat64 variant, then the translation
> layer is needed anyway and we should maybe use the asm-generic 64-bit
> struct stat variant of the layout on all 32-bit platforms.)
Understood -- but as soon as 64-bit-time types are frozen on the kernel
side, we could freeze the corresponding GLIBC API types (hopefully
without a translation layer needed) and then if GLIBC gets out there
before the kernel does, it won't be a problem since in any case the
64-bit-time implementation must fall back to 32-bit syscalls if the
64-bit syscalls return an ENOSYS.
Cordialement,
Albert ARIBAUD
3ADEV