diff options
author | Arnd Bergmann <arnd@arndb.de> | 2019-01-06 23:45:29 +0100 |
---|---|---|
committer | Arnd Bergmann <arnd@arndb.de> | 2019-02-07 00:13:28 +0100 |
commit | d33c577cccd0b3e5bb2425f85037f26714a59363 (patch) | |
tree | a068ddb9cdb828c347c6a60679c5471cf2f7c21b /arch/alpha | |
parent | c70a772fda11570ebddecbce1543a3fda008db4a (diff) | |
download | talos-op-linux-d33c577cccd0b3e5bb2425f85037f26714a59363.tar.gz talos-op-linux-d33c577cccd0b3e5bb2425f85037f26714a59363.zip |
y2038: rename old time and utime syscalls
The time, stime, utime, utimes, and futimesat system calls are only
used on older architectures, and we do not provide y2038 safe variants
of them, as they are replaced by clock_gettime64, clock_settime64,
and utimensat_time64.
However, for consistency it seems better to have the 32-bit architectures
that still use them call the "time32" entry points (leaving the
traditional handlers for the 64-bit architectures), like we do for system
calls that now require two versions.
Note: We used to always define __ARCH_WANT_SYS_TIME and
__ARCH_WANT_SYS_UTIME and only set __ARCH_WANT_COMPAT_SYS_TIME and
__ARCH_WANT_SYS_UTIME32 for compat mode on 64-bit kernels. Now this is
reversed: only 64-bit architectures set __ARCH_WANT_SYS_TIME/UTIME, while
we need __ARCH_WANT_SYS_TIME32/UTIME32 for 32-bit architectures and compat
mode. The resulting asm/unistd.h changes look a bit counterintuitive.
This is only a cleanup patch and it should not change any behavior.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Diffstat (limited to 'arch/alpha')
0 files changed, 0 insertions, 0 deletions