unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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


             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).