Re: [PATCH] Y2038: provide kernel support indication

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

Hi Joseph,

On Wed, 19 Sep 2018 13:03:21 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :

> On Wed, 19 Sep 2018, Albert ARIBAUD (3ADEV) wrote:
> 
> > * New function __y2038_get_kernel_support() returns:
> >   * 0 if the underlying kernel does not support Y2038 at all
> >   * > 0 if the underlying kernel has some support for Y2038
> >   * < 0 if the underlying kernel support for Y2038 is broken
> > * New function __y2038_set_kernel_support() allows indicating
> >   a kernel's Y2038 support (or support failure)
> > * Default implementation (covering non-Linux kernels) always
> >   returns 0 (no support).  
> 
> There should be an __ASSUME_* macro that kernel-features.h defines when 
> the minimum kernel version has the required feature.  Calls to these APIs 
> need to become compile-time constants in that case, with the functions / 
> variables not existing in the glibc binaries at all.

Ok, how about __ASSUME_KERNEL_Y2038_SUPPORT?

In case it is not defined, then all Y2038 feature support calls would
return 'no support'.

Considering right now no kernel has 64-bit-time syscalls (there is only
a patch series / development branch which provides some for some
architectures), __ASSUME_KERNEL_Y2038_SUPPORT should remain undefined
(but I will define it for testing with the dev branch).

So what is the best option:

- not define it at all (at the risk of people wondering why I am
  referring to an undefined __ASSUME_*)

- Just #undef it in sysdeps/unix/sysv/linux/kernel-features.h even
  though it is not #define'd elsewhere?

- #define it in sysdeps/unix/sysv/linux/kernel-features.h and then
  #undef it in sysdeps/unix/sysv/linux/*/kernel-features.h, and later
  when some architecture gets Y2038 syscall support, remove its #undef?

> > +  GLIBC_2.29 {
> > +    __y2038_get_kernel_support;
> > +    __y2038_set_kernel_support;
> > +  }  
> 
> I don't think these should be public interfaces (but if they were, the 
> patch would need to update all the ABI test baselines).  If exported for 
> use by other glibc shared libraries, they should be exported at version 
> GLIBC_PRIVATE.  (That does require they are never used in code in 
> *_nonshared.a because that may end up in users' programs / shared 
> libraries, but very little should go in *_nonshared.a.)

Indeed, some glibc shared libs will need those, but there is little
reason that public code should use them. I will switch to GLIBC_PRIVATE
(but the names and number of functions will probably change, see Paul's
comments re Y2038 features).

Cordialement,
Albert ARIBAUD
3ADEV