This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Y2038: provide kernel support indication
Hi Joseph,
On Tue, 25 Sep 2018 20:25:22 +0000, Joseph Myers
<joseph@codesourcery.com> 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.
Cordialement,
Albert ARIBAUD
3ADEV