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, Sep 8, 2017 at 2:16 PM, Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
> 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.
I think that's right. Syscalls we can add support for later, types
are much more troublesome.
zw