This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Y2038: provide kernel support indication
On Wed, 26 Sep 2018, Albert ARIBAUD wrote:
> I don't think 64-bit architectures will get the new __NR_* names, but
> if they do, I think that they will point to the old numbers, i.e.,
> Y2038 support should not introduce new syscalls on 64-bit
> architectures (as these syscalls would basically be the same as
> existing ones).
This is where Arnd said in
<https://sourceware.org/ml/libc-alpha/2018-09/msg00452.html> he was
Having new numbers for the old syscalls doesn't provide anything useful to
glibc since we'd want in some cases to avoid using those new numbers.
Having new names for the old syscall numbers is fairly harmless; it might
simplify some code in glibc if it means __ASSUME_KERNEL_Y2038_SUPPORT can
be defined for 64-bit, but it might also complicate things (glibc would
need to define the new names to the old ones when building with old kernel
headers, __ASSUME_KERNEL_Y2038_SUPPORT would probably need to be split
into two if there are genuinely new syscalls for 64-bit for the itimerval
/ rusage cases).
> - if undefined, we try the new names and numbers and on ENOSYS we fall
> back to the old names and numbers.
With of course compile-time conditionals to handle the case when the new
names aren't defined at all, so we can only use the old syscalls without
such runtime conditionals.
Joseph S. Myers