From: Lukasz Majewski <lukma@denx.de>
To: libc-alpha@sourceware.org, Joseph Myers <joseph@codesourcery.com>
Cc: Stepan Golosunov <stepan@golosunov.pp.ru>,
Arnd Bergmann <arnd@arndb.de>, Paul Eggert <eggert@cs.ucla.edu>,
Lukasz Majewski <lukma@denx.de>
Subject: [PATCH] y2038: Introduce __ASSUME_TIME64_SYSCALLS define
Date: Mon, 17 Jun 2019 17:42:29 +0200 [thread overview]
Message-ID: <20190617154229.2106-1-lukma@denx.de> (raw)
This define indicates if the Linux kernel provides interfaces (syscalls)
to support 64 bit time.
* sysdeps/unix/sysv/linux/kernel-features.h:
(__ASSUME_TIME64_SYSCALLS): Define.
---
Changes for v8:
- Be more specific about the "current" and "present" description of archs
with 64 bit time support.
- Check if eligible 64 bit time related syscalls are defined for 3.2 kernel
Changes for v7:
- Move the flag description from commit message to in-code comment.
- Check if relevant syscalls were defined in v3.2 (oldest glibc supported
kernel).
- New syscalls, added to v5.1, like semtimedop_time64, which need extra
code for handling, shall be excluded from __ASSUME_TIME64_SYSCALLS and
would receive new flag - e.g. __ASSUME_SEMTIMEDOP_TIME64
Changes for v6:
- Change the logical meaning of __ASSUME_TIME64_SYSCALLS - now it
indicates if the system supports the 64 bit time ABI (if for both
__WORDSIZE==64 and __WORDSIZE==32 systems equally functional syscalls
are provided).
- Update commit description
Changes for v5:
- Rewrite the in-code comment (x32 description more precise)
- Change patch description (for x32)
Changes for v4:
- Exclude this patch from the clock_settime64 patch series
- Rewrite the in-code comment
- Change patch description
Changes for v3:
- Provide more detailed and verbose description
- Change name to __ASSUME_TIME64_SYSCALLS
- Undefine __ASSUME_TIME64_SYSCALLS on x32
Changes for v2:
- New patch
Syscall's ABI compatibility checking:
Assumptions:
- syscall ABI change require changing the name - like __NR_epoll_create
and __NR_epoll_create1
- once added syscall with a name (e.g. __NR_epoll_create) will have thes
same interface (ABI)
0. List of 64 bit archs to be checked (there is no need to check 32 bit
archs as they will use a separate set of syscalls from v5.1 Linux
kernel):
aarch64 (arm64)
alpha
ia64
mips (n64 and n32 syscall ABIs)
powerpc (64-bit syscall ABI)
riscv (64-bit syscall ABI)
s390 (64-bit syscall ABI)
sparc (64-bit syscall ABI)
x86_64 (classic and x32 syscall ABIs)
1. Code to check if syscalls are defined since v3.2 kernel
export syscalls_table="\
clock_gettime clock_settime clock_adjtime \
clock_getres clock_nanosleep timer_gettime \
timer_settime timerfd_gettime timerfd_settime \
utimensat pselect6 ppoll io_pgetevents recvmmsg \
mq_timedsend mq_timedreceive rt_sigtimedwait futex \
sched_rr_get_interval"
for syscall in ${syscalls_table} ; do echo -n "syscall: ${syscall} -> "; \
grep -rnIw "__NR_${syscall}" | grep ^arch/ | \
grep -vE "mn10300|avr32|cris|m32r|frv|blackfin|xtensa|h8300|vdso|m68k\
|sh|microblaze" | \
wc -l; done
Excluded syscalls (needs to be re-checked when syscall is converted to
64 bit):
- recvmmsg - up to v4.3 is not defined for s390 (64 bit) (the sys_socketcall()
is used instead)
- io_pgetevents - is not defined at all for 3.2 kernel archs
Each file from the above script has been examined to look for any
#if or comment (grep -C1) for the relevant syscall.
2. Architectures (ports) supported by current glibc
(SHA1: 48c3c1238925410b4e777dc94e2fde4cc9132d44), but added to Linux
after v3.2 (for those the oldest supported kernel by glibc is the
version with which it has been added):
(New, 32 bit ports - nios2, csky, hppa are excluded as they gain 64 bit
time support from v5.1 onwards)
Relevant 64 bit new ports: aarch64 (arm64), riscv -
the __ASSUME_TIME64_SYSCALLS set of syscalls is defined for them.
To sum up:
==========
- We need to exclude recvmmsg and io_pgetevents from __ASSUME_TIME64_SYSCALLS
- Other syscalls were available since 3.2
---
sysdeps/unix/sysv/linux/kernel-features.h | 73 +++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/sysdeps/unix/sysv/linux/kernel-features.h b/sysdeps/unix/sysv/linux/kernel-features.h
index bc5c959f58..989e02435c 100644
--- a/sysdeps/unix/sysv/linux/kernel-features.h
+++ b/sysdeps/unix/sysv/linux/kernel-features.h
@@ -143,3 +143,76 @@
*/
#define __ASSUME_CLONE_DEFAULT 1
+
+/* This flag indicates support for Linux kernel syscalls, which are able
+ to handle 64 bit time ABI. It is defined for architectures which use
+ unsuffixed time related, 64 bit syscalls (and define __WORDSIZE == 64
+ __SYSCALL_WORDSIZE == 64) as well as ones gaining it with new syscalls
+ added to Linux kernel version 5.1 (listed below).
+
+ To be more specific - this flag focuses on higer level of abstraction,
+ which indicates the system's ability to support 64 bit time.
+
+ In the other words this flag indicates availability of specific 64 bit
+ time supporting interfaces (syscalls in this case) from Linux kernel.
+
+ As an example - the syscall to set clock (clock_settime) - if the
+ __ASSUME_TIME64_SYSCALLS is defined, it indicates that 64 bit time can
+ be set in the system.
+
+ On systems with __WORDSIZE == 64 the __NR_clock_settime syscall is used
+ to achieve this goal. Contrary, systems with __WORDSIZE == 32 do use the
+ new __NR_clock_settime64 syscall (with suffix) available from Linux
+ version 5.1.
+
+ The __ASSUME_TIME64_SYSCALLS is defined for:
+
+ 1. Systems which use syscalls with unsuffixed names (like clock_settime)
+ to provid 64 bit time support (__WORDSIZE == 64).
+
+ 2. For 'x32' architecture, which is a special case in respect to 64 bit
+ time support (it has __WORDSIZE == 32 but __TIMESIZE == 64)
+
+ For point 1 and 2, defined __ASSUME_TIME64_SYSCALL means, that the
+ syscall semantics are identical for both the old syscall (on systems
+ where __WORDSIZE or _SYSCALL_WORDSIZE is 64) and for the new one (if
+ ever defined from listed below v5.1 subset), so that no code will
+ ever have to handle the two syscalls differently.
+
+ 3. Systems with __WORDSIZE == 32, which gain 64 bit time support with
+ new set of syscalls added to Linux kernel 5.1.
+
+ List of new syscalls added to v5.1. kernel (they accept data based on
+ struct timespec and timeval with 64 bit tv_sec) consistent with
+ __ASSUME_TIME64_SYSCALLS flag definition:
+
+ clock_gettime64
+ clock_settime64
+ clock_adjtime64
+ clock_getres_time64
+ clock_nanosleep_time64
+ timer_gettime64
+ timer_settime64
+ timerfd_gettime64
+ timerfd_settime64
+ utimensat_time64
+ pselect6_time64
+ ppoll_time64
+ mq_timedsend_time64
+ mq_timedreceive_time64
+ rt_sigtimedwait_time64
+ futex_time64
+ sched_rr_get_interval_time64
+
+ Listed above syscalls have counterparts (with unsuffixed syscalls names)
+ already providing 64 bit time support on systems with __WORDSIZE == 64 or
+ __SYSCALL_WORDSIZE == 64 since the oldest supported by glibc Linux kernel
+ (v3.2). */
+
+#include <bits/wordsize.h>
+#if (__WORDSIZE == 64 \
+ || (__WORDSIZE == 32 \
+ && (__LINUX_KERNEL_VERSION >= 0x050100 \
+ || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64))))
+# define __ASSUME_TIME64_SYSCALLS 1
+#endif
--
2.11.0
next reply other threads:[~2019-06-17 15:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 15:42 Lukasz Majewski [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-04-14 22:08 [PATCH 0/6] y2038: Linux: Provide __clock_* functions supporting 64 bit time Lukasz Majewski
2019-05-08 15:56 ` [PATCH] y2038: Introduce __ASSUME_TIME64_SYSCALLS define Lukasz Majewski
2019-05-09 15:58 ` Joseph Myers
2019-05-09 16:18 ` Stepan Golosunov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190617154229.2106-1-lukma@denx.de \
--to=lukma@denx.de \
--cc=arnd@arndb.de \
--cc=eggert@cs.ucla.edu \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=stepan@golosunov.pp.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).