[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Aug 2019 15:12:21 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 0/7] updates for linux v5.2
On Tue, Aug 20, 2019 at 12:31:39PM +0200, Szabolcs Nagy wrote:
> From d93bcfff5a73a15025723c4b8f76cac5f4145c0e Mon Sep 17 00:00:00 2001
> From: Szabolcs Nagy <nsz@...t70.net>
> Date: Mon, 12 Aug 2019 18:21:47 +0000
> Subject: [PATCH 3/7] fcntl.h: add existing linux specific AT_ definitions
>
> AT_NO_AUTOMOUNT: suppress terminal automount traversal
> AT_EMPTY_PATH: allow empty relative pathname
> AT_STATX_SYNC_TYPE: statx sync flag
> AT_STATX_SYNC_AS_STAT: statx sync flag
> AT_STATX_FORCE_SYNC: statx sync flag
> AT_STATX_DONT_SYNC: statx sync flag
>
> follow glibc which exposes these under _GNU_SOURCE.
> ---
> include/fcntl.h | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/fcntl.h b/include/fcntl.h
> index af293405..51ec7efa 100644
> --- a/include/fcntl.h
> +++ b/include/fcntl.h
> @@ -63,6 +63,15 @@ int posix_fallocate(int, off_t, off_t);
> #define AT_SYMLINK_FOLLOW 0x400
> #define AT_EACCESS 0x200
>
> +#ifdef _GNU_SOURCE
> +#define AT_NO_AUTOMOUNT 0x800
> +#define AT_EMPTY_PATH 0x1000
> +#define AT_STATX_SYNC_TYPE 0x6000
> +#define AT_STATX_SYNC_AS_STAT 0x0000
> +#define AT_STATX_FORCE_SYNC 0x2000
> +#define AT_STATX_DONT_SYNC 0x4000
> +#endif
> +
We already have the first two, under BSD||GNU. Note that non-exposure
under plain POSIX is not a choice here; AT_* is (perhaps wrongly, by
oversight) not in the reserved namespace for fcntl.h.
I'm not sure if GNU-only is better than BSD||GNU; my leaning is
towards keeping the latter.
> From 0d098fb03b47a1005ff841fa74cb017f2f79baf1 Mon Sep 17 00:00:00 2001
> From: Szabolcs Nagy <nsz@...t70.net>
> Date: Mon, 12 Aug 2019 18:48:35 +0000
> Subject: [PATCH 5/7] add new syscall numbers from linux v5.2
>
> new mount api syscalls were added, same numers on all targets, see
>
> linux commit a07b20004793d8926f78d63eb5980559f7813404
> vfs: syscall: Add open_tree(2) to reference or clone a mount
>
> linux commit 2db154b3ea8e14b04fee23e3fdfd5e9d17fbc6ae
> vfs: syscall: Add move_mount(2) to move mounts around
>
> linux commit 24dcb3d90a1f67fe08c68a004af37df059d74005
> vfs: syscall: Add fsopen() to prepare for superblock creation
>
> linux commit ecdab150fddb42fe6a739335257949220033b782
> vfs: syscall: Add fsconfig() for configuring and managing a context
>
> linux commit 93766fbd2696c2c4453dd8e1070977e9cd4e6b6d
> vfs: syscall: Add fsmount() to create a mount for a superblock
>
> linux commit cf3cba4a429be43e5527a3f78859b1bfd9ebc5fb
> vfs: syscall: Add fspick() to select a superblock for reconfiguration
>
> linux commit 9c8ad7a2ff0bfe58f019ec0abc1fb965114dde7d
> uapi, x86: Fix the syscall numbering of the mount API syscalls [ver #2]
>
> linux commit d8076bdb56af5e5918376cd1573a6b0007fc1a89
> uapi: Wire up the mount API syscalls on non-x86 arches [ver #2]
> ---
> arch/aarch64/bits/syscall.h.in | 6 ++++++
> arch/arm/bits/syscall.h.in | 6 ++++++
> arch/i386/bits/syscall.h.in | 6 ++++++
> arch/m68k/bits/syscall.h.in | 6 ++++++
> arch/microblaze/bits/syscall.h.in | 6 ++++++
> arch/mips/bits/syscall.h.in | 6 ++++++
> arch/mips64/bits/syscall.h.in | 6 ++++++
> arch/mipsn32/bits/syscall.h.in | 6 ++++++
> arch/or1k/bits/syscall.h.in | 6 ++++++
> arch/powerpc/bits/syscall.h.in | 6 ++++++
> arch/powerpc64/bits/syscall.h.in | 6 ++++++
> arch/riscv64/bits/syscall.h.in | 7 +++++++
> arch/s390x/bits/syscall.h.in | 6 ++++++
> arch/sh/bits/syscall.h.in | 6 ++++++
> arch/x32/bits/syscall.h.in | 6 ++++++
> arch/x86_64/bits/syscall.h.in | 6 ++++++
> 16 files changed, 97 insertions(+)
>
> diff --git a/arch/aarch64/bits/syscall.h.in b/arch/aarch64/bits/syscall.h.in
> index eed5a612..955e2cab 100644
> --- a/arch/aarch64/bits/syscall.h.in
> +++ b/arch/aarch64/bits/syscall.h.in
> @@ -281,4 +281,10 @@
> #define __NR_io_uring_setup 425
> #define __NR_io_uring_enter 426
> #define __NR_io_uring_register 427
> +#define __NR_open_tree 428
> +#define __NR_move_mount 429
> +#define __NR_fsopen 430
> +#define __NR_fsconfig 431
> +#define __NR_fsmount 432
> +#define __NR_fspick 433
> [...]
I think this is okay for now, but now that Linux has unified syscall
numbers for all future syscalls, I wonder if we should add a
bits/syscall_common.h or something that defines all the common ones in
terms of some base macro, so that we don't have O(nm) growth here.
Just a comment on possible future enhancement so the thought is
recorded somewhere.
> From 41f792f83ea6fcd009651e718e36db80f8153f52 Mon Sep 17 00:00:00 2001
> From: Szabolcs Nagy <nsz@...t70.net>
> Date: Mon, 12 Aug 2019 19:26:08 +0000
> Subject: [PATCH 7/7] sys/ioctl.h: add time_t abi related ioctls from linux
> v5.2
>
> TODO: this is similar to the uncommitted linux v5.1 SO_TIMESTAMP_{NEW,OLD}
> socket option changes.
>
> instead of explicit number, the _IOR macro is used, so same definition
> works on mips and powerpc (and the long long[2] type is available
> without header includes)
> ---
> include/sys/ioctl.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/sys/ioctl.h b/include/sys/ioctl.h
> index 372e3ddc..73245afa 100644
> --- a/include/sys/ioctl.h
> +++ b/include/sys/ioctl.h
> @@ -116,6 +116,11 @@ struct winsize {
> #define SIOCDEVPRIVATE 0x89F0
> #define SIOCPROTOPRIVATE 0x89E0
>
> +#define SIOCGSTAMP_OLD SIOCGSTAMP
> +#define SIOCGSTAMPNS_OLD SIOCGSTAMPNS
> +#define SIOCGSTAMP_NEW _IOR(0x89, 0x06, long long[2])
> +#define SIOCGSTAMPNS_NEW _IOR(0x89, 0x07, long long[2])
> +
> int ioctl (int, int, ...);
As before, the _OLD/_NEW names aren't needed for userspace. Rather the
definition of the unadorned macro has to be changed from the old value
to the new one when the time64 switchover happens (missing from the
RFC/POC i386 commit in the "final time64 switch-over patch series"
thread -- this needs fixing). The _OLD versions are already defined
privately in arch/*/syscall_arch.h for 32-bit archs since commit
2e554617e5a6a41bf3f6c6306c753cd53abf728c, so ioctl.c can use them for
translation.
Also, I don't think it matters whether the _IOR macro is used or not
since the naive switchover will require per-arch ioctl bits for all
32-bit archs, but maybe we can come up with a way to share some of the
bits stuff between them and prevent introduction of new redundancy.
Thoughts?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
