summaryrefslogtreecommitdiffstats
path: root/arch/m68k/kernel/relocate_kernel.S
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2019-01-10 12:45:11 +0100
committerArnd Bergmann <arnd@arndb.de>2019-02-07 00:13:28 +0100
commit48166e6ea47d23984f0b481ca199250e1ce0730a (patch)
tree1af2bed895bab4bd048a389dd7d63c68e5d5a7c6 /arch/m68k/kernel/relocate_kernel.S
parentd33c577cccd0b3e5bb2425f85037f26714a59363 (diff)
downloadlinux-48166e6ea47d23984f0b481ca199250e1ce0730a.tar.bz2
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 'arch/m68k/kernel/relocate_kernel.S')
0 files changed, 0 insertions, 0 deletions