Re: [PATCH] Y2038: provide kernel support indication

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

Hi Arnd,

On Tue, 25 Sep 2018 22:14:38 +0200, Arnd Bergmann <arnd@arndb.de>
wrote :

> On Tue, Sep 25, 2018 at 9:36 PM Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
> >
> > CC:ing Arnd re whether all 32-bit architectures will get 64-bit-time
> > kernel support.
> >
> > On Tue, 25 Sep 2018 17:25:39 +0000, Joseph Myers
> > <joseph@codesourcery.com> wrote :  
> > > On Mon, 24 Sep 2018, Albert ARIBAUD wrote:
> > > Before we work out what the macro (or macros if more than one is needed)
> > > is called, and the semantics of it being defined or undefined, we need to
> > > have a clear understanding of the semantics.  And that in turn requires a
> > > clear understanding of what the future kernel interfaces will be.
> > >
> > > Could you provide a description of what the kernel interfaces will be in
> > > future for each of the following cases (and any other significantly
> > > different variants I've missed)?  Then, indicate whether you'd expect the
> > > __ASSUME_* macro or macros to be defined in each of those cases.
> > > Hopefully this will help clarify what the interfaces should look like
> > > within glibc.  (This information will also need to go in the proposed
> > > glibc commit messages for future versions of the present patch, and quite
> > > likely some of it should go in comments in glibc code.)
> > >
> > >
> > > 1a. Existing 64-bit architectures, where 64-bit time_t is the only variant
> > > supported, in both the kernel and (if those architectures already have
> > > glibc ports) glibc.
> > >
> > > My expectation is that these will *not* provide any new syscalls and will
> > > *not* provide any new __NR_* aliases for existing syscalls.  Is that
> > > correct?  
> >
> > Yes, that is correct.  
> 
> I was undecided on this issue actually: it does make some sense to
> me to have the syscall macros be the same in the long run, so that
> glibc doesn't have to pick between __NR_clock_gettime and
> __NR_clock_gettime64 in a few years, after all supported kernels
> support __NR_clock_gettime64. Also, 64-bit architectures won't
> reuse the number space that we reserve for the new calls on 32-bit
> architectures, so the addition is essentially free.
> 
> OTOH, it does seem a bit silly to have two syscall numbers that
> point to the same symbol.

I'd say this double naming would be justified by the will to transition
from the 'old' to the 'new' symbols.

> I don't have a strong preference here, and can do whichever
> you like better in glibc.

There does not seem to have been any other comment on this for a while, 
so, do we go for this approach? That is:

- on 64-bit architectures, the kernel will define _NR symbols identical
  to those added for Y2038, so that, for instance, on X86_64, there
  will be an _NR_clock_gettime64 symbol (which will point to the same
  syscall number as _NR_clock_gettime does).

- on 64-bit architectures, GLIBC will set __ASSUME_KERNEL_Y2038_SUPPORT
  once the minimal kernel supported version for these architectures
  provides the 'new' syscall symbols.

- on all architectures, if __ASSUME_KERNEL_Y2038_SUPPORT is defined,
  then GLIBC assumes the 'new' syscall symbols exist and can be used.

- on all architectures, if __ASSUME_KERNEL_Y2038_SUPPORT is NOT defined,
  then GLIBC will try to use new syscalls for which a _NR symbol is
  provided by the build-time kernel, and on ENOSYS, will fallback to old
  syscalls.

Cordialement,
Albert ARIBAUD
3ADEV