This is the mail archive of the 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

Hi Joseph,

On Tue, 25 Sep 2018 20:25:22 +0000, Joseph Myers
<> wrote :

> On Tue, 25 Sep 2018, Joseph Myers wrote:
> > Yes, subject to the question of what's appropriate on 64-bit architectures 
> > where time_t always has been 64-bit and the existing names of syscalls, 
> > not the new ones, are used for all time-related syscalls.  If 
> > __ASSUME_KERNEL_Y2038_SUPPORT means the syscalls with the new names are 
> > guaranteed to be present, then it should be undefined in that case because 
> > only the old names will be present (but also the variable etc. relating to 
> > runtime tests for support should not be declared at all, so if any code 
> > with such tests is - wrongly - compiled on such an architecture, it will 
> > fail to compile).  
> There is of course also a possible variant for 64-bit architectures if it 
> proves better for the implementation:
> * Make a glibc-internal header #define all the __NR_* for the new syscall 
> names to point to the old names if the kernel headers don't do so.
> * Define __ASSUME_KERNEL_Y2038_SUPPORT unconditionally for such 
> architectures, because the syscalls in question are in fact old ones so 
> always present at runtime.  (If the kernel headers might define the new 
> __NR_* names *and point them to new syscall numbers*, it's more 
> complicated, because in that case it would no longer be correct to assume 
> the syscalls are available with an old kernel, but it would be completely 
> useless to have runtime checks to decide between using old and new syscall 
> numbers for the same syscall.  Also, if there are new syscalls that e.g. 
> use timespec where existing ones use timeval and so are genuinely new even 
> on 64-bit architectures, you'd end up needing to split 
> __ASSUME_KERNEL_Y2038_SUPPORT into separate macros for the separate groups 
> of syscalls.)

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

So I would tend to favor your variant approach above, as it makes the
semantics of __ASSUME_KERNEL_Y2038_SUPPORT simpler:

- if defined, we just use the new __NR_* names and 64-bit times, even
  for 64-bit architectures (with new names mapped to old names/numbers
  either by the kernel or by us);

- if undefined, we try the new names and numbers and on ENOSYS we fall
  back to the old names and numbers. 


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