diff options
author | Arnd Bergmann <arnd@arndb.de> | 2019-01-10 12:45:11 +0100 |
---|---|---|
committer | Arnd Bergmann <arnd@arndb.de> | 2019-02-07 00:13:28 +0100 |
commit | 48166e6ea47d23984f0b481ca199250e1ce0730a (patch) | |
tree | 1af2bed895bab4bd048a389dd7d63c68e5d5a7c6 /kernel/sched/core.c | |
parent | d33c577cccd0b3e5bb2425f85037f26714a59363 (diff) | |
download | linux-stable-48166e6ea47d23984f0b481ca199250e1ce0730a.tar.gz linux-stable-48166e6ea47d23984f0b481ca199250e1ce0730a.tar.bz2 linux-stable-48166e6ea47d23984f0b481ca199250e1ce0730a.zip |
y2038: add 64-bit time_t syscalls to all 32-bit architectures
This adds 21 new system calls on each ABI that has 32-bit time_t
today. All of these have the exact same semantics as their existing
counterparts, and the new ones all have macro names that end in 'time64'
for clarification.
This gets us to the point of being able to safely use a C library
that has 64-bit time_t in user space. There are still a couple of
loose ends to tie up in various areas of the code, but this is the
big one, and should be entirely uncontroversial at this point.
In particular, there are four system calls (getitimer, setitimer,
waitid, and getrusage) that don't have a 64-bit counterpart yet,
but these can all be safely implemented in the C library by wrapping
around the existing system calls because the 32-bit time_t they
pass only counts elapsed time, not time since the epoch. They
will be dealt with later.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Diffstat (limited to 'kernel/sched/core.c')
0 files changed, 0 insertions, 0 deletions