Re: [PATCH] Y2038: provide kernel support indication

[Joseph Myers <joseph at codesourcery dot com>]

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

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?

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.


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.


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.


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?

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.

> - #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?

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.

-- 
Joseph S. Myers
joseph@codesourcery.com