Re: [PATCH] Y2038: provide kernel support indication

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

Hi Joseph,

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:
> 
> > > 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'.  
> 
> Well, normally "not defined" for __ASSUME_* doesn't mean "no support"; it 
> means "support may or may not be present, and needs to be tested for at 
> runtime if the __NR_* macros in question are defined".

So, assuming V is the version at which 64-bit-time kernel support is
introduced for all architectures at the same time:

- if the minimal kernel version supported by glibc for a given
  architecture is less than V, then __ASSUME_KERNEL_Y2038_SUPPORT should
  be undefined and glibc should check dynamically whether the actual
  kernel it is running on has 64-bit-time support or not;

- if the minimal kernel version supported by glibc for a given
  architecture is V or greater, then __ASSUME_KERNEL_Y2038_SUPPORT
  should be defined and glibc checks for support should be turned
  into constants so that 64-bit-time syscalls are systematically
  called.

Correct?

> 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.

> If so, would the __ASSUME_* macro be defined for those architectures or 
> not?  Whether it is or not, there must *not* be any new variables or 
> internal functions defined in glibc at all relating to Y2038 support, or 
> any additional levels of function calls / wrappers at runtime when 
> time-related glibc functions are used, given that there are no Y2038 
> problems for those architectures at present anyway.  (Avoiding such extra 
> code and data might involve e.g. __TIMESIZE conditionals.  Naturally it's 
> *also* desirable to design the implementation internals to reduce the 
> number of places needing such conditionals.)
> 
> 
> 1b. New 64-bit architectures (not currently supported in the kernel).
> 
> My expectation is that these will be the same as old ones - they will 
> provide the existing syscalls (minus obsolete ones), under their existing 
> names, not any new ones that explicitly reference 64-bit time.  Is that 
> correct?  If so, I'd expect them to look exactly like case 1a in glibc.

I think this is correct.

> 2a. Existing 32-bit architectures, supported in both the kernel and glibc 
> with 32-bit time_t.
> 
> These will all need to gain new syscalls under new names, with the new 
> macro defined when those syscalls are known to be available at runtime.

Correct.

> 2b. Existing 32-bit architectures, already supported in the kernel, but 
> not supported in glibc until after the 64-bit time support is present in 
> both places.
> 
> >From the point of view of the kernel, these should be exactly like case   
> 2a.  But from the point of view of glibc, they might be different - we 
> might want to support only 64-bit time for them (so __TIMESIZE would be 
> 64, and _TIME_BITS=64 would do nothing).  Is that what you'd intend for 
> such new architectures in glibc?  If so, presumably the __ASSUME_* macro 
> would still be defined for them, but the combination of that macro and 
> __TIMESIZE == 64 might end up doing different things in some places?  And 
> would the glibc port for such an architecture allow runtime fallback to 
> 32-bit time syscalls, or would it also require a minimum kernel with 
> 64-bit time support rather than allowing older kernels from before the 
> glibc port was added?
> 
> (Of course you can't really test this combination; it may fall to whoever 
> adds the first such architecture port to glibc to get it working.)
> 
> Another consideration for such architectures is whether you end up with 
> the combination of 64-bit time and 32-bit file offsets for them (given 
> _TIME_BITS=64 requires _FILE_OFFSET_BITS=64, but here you have 64-bit time 
> without defining _TIME_BITS).  It might make sense for such architectures 
> also to use 64-bit offsets unconditionally, like 64-bit architectures do, 
> so that defining _FILE_OFFSET_BITS=64 for them only affects mangling for a 
> few types, not layout.

As you point out, I won't test for this combination, but yes, my
opinion is that 32-bit architectures which are supported in the kernel
but not yet in glibc should only use 64-bit time syscalls when glibc
support is added.

> 3. New 32-bit architectures (new in both kernel and glibc after the 
> addition of 64-bit time support for 32-bit architectures in the kernel).
> 
> My expectation is that these will *only* have the new-named syscalls for 
> 64-bit time, not the old-named syscalls that use 32-bit time on 32-bit 
> systems (and not the old syscall names but pointing to syscalls that use 
> 64-bit time, either).  Is that correct - new-named syscalls only for 
> everything involving time on such architectures?

I think this is correct.

> Then I'd expect those to look much like case 2b within glibc, except that 
> arch_minimum_kernel would be recent enough that any code that might 
> attempt to fall back to 32-bit-time syscalls would be compiled out.
> 
> > - Just #undef it in sysdeps/unix/sysv/linux/kernel-features.h even
> >   though it is not #define'd elsewhere?  
> 
> I think this, or a commented-out definition with the comment explaining 
> the intended semantics.

Ok.

> > - #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?  
> 
> I'd hope all 32-bit architectures get kernel support at the same time.  
> Is that the intent, or is something else intended?

Arnd would know this much better than I do.

> If 64-bit architectures should have the macro undefined, then 
> sysdeps/unix/sysv/linux/kernel-features.h will need to have a conditional 
> deciding whether to undefine it, based on "is this an architecture for 
> which the ordinary time syscalls always use 64-bit time_t?".  That 
> conditional is *not* quite __WORDSIZE == 64, in that such a conditional 
> would be wrong for x32, but it's also not __TIMESIZE == 64, if the answer 
> for cases 2b and 3 above is that they would have __TIMESIZE == 64.  
> Supposing that is indeed the case for cases 2b and 3, it would seem 
> reasonable to use __WORDSIZE == 64 in the generic kernel-features.h and 
> then override it in x86_64/kernel-features.h.  What we *don't* want is a 
> situation where all future 32-bit architectures need to have their own 
> overrides - the default case for future architectures must be not needing 
> their own kernel-features.h file at all.

Cordialement,
Albert ARIBAUD
3ADEV