This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]