[RFC] kernel/libc uapi changes for y2038
In the patch series I posted recently [1], I introduce new system calls to deal
with modified data structures, but left the question open on how these should
be best accessed from libc. The patches introduce a new __kernel_time64_t type
and based on that five new data structured: struct __kernel_timespec,
struct __kernel_itimerspec, struct __kernel_stat, struct __kernel_rusage,
and struct __kernel_timex. This works fine for the case when all libc
implementations provide their own definitions to user space, but not for
the simplest case (e.g. klibc) where the user-visible structures come directly
from the kernel uapi headers.
I still don't know what model the various libc developers prefer, so here is
an alternative approach, as a patch on top of the previous series:
Now, we rename the original structures to struct __old_kernel_*, and use a
macro to define either the __old_kernel_* or the __kernel_* structure name
to the name we actually want in user space, based on a __KERNEL_TIME_BITS
macro that can be set to either 32 or 64 for 32-bit architectures by
the libc. Depending on that macro, the compiler will either see one
of these combinations (for each of the five structures):
a) __BITS_PER_LONG == 32 && __KERNEL_TIME_BITS == 32:
struct timespec based on 32-bit __kernel_time_t
struct __kernel_timespec based on 64-bit __kernel_time64_t
b) __BITS_PER_LONG == 64 && __KERNEL_TIME_BITS == 64:
struct timespec based on 64-bit __kernel_time_t
struct __kernel_timespec based on 64-bit __kernel_time64_t
c) __BITS_PER_LONG == 32 && __KERNEL_TIME_BITS == 64:
struct __old_kernel_timespec based on 32-bit __kernel_time_t
struct timespec based on 64-bit __kernel_time64_t
Would this work for everyone? Any alternative suggestions?
Arnd
[1] http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/log/?h=y2038-syscalls
https://lwn.net/Articles/643407/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
22 files changed
