This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] uapi: split openat2(2) definitions from fcntl.h
- From: Florian Weimer <fweimer at redhat dot com>
- To: Aleksa Sarai <cyphar at cyphar dot com>
- Cc: Alexander Viro <viro at zeniv dot linux dot org dot uk>, Jeff Layton <jlayton at kernel dot org>, "J. Bruce Fields" <bfields at fieldses dot org>, Shuah Khan <shuah at kernel dot org>, David Laight <david dot laight at aculab dot com>, Christian Brauner <christian dot brauner at ubuntu dot com>, dev at opencontainers dot org, containers at lists dot linux-foundation dot org, libc-alpha at sourceware dot org, linux-api at vger dot kernel dot org, linux-fsdevel at vger dot kernel dot org, linux-kernel at vger dot kernel dot org, linux-kselftest at vger dot kernel dot org
- Date: Thu, 19 Dec 2019 12:07:13 +0100
- Subject: Re: [PATCH 1/2] uapi: split openat2(2) definitions from fcntl.h
- References: <20191219105533.12508-1-cyphar@cyphar.com> <20191219105533.12508-2-cyphar@cyphar.com>
* Aleksa Sarai:
> diff --git a/include/uapi/linux/openat2.h b/include/uapi/linux/openat2.h
> new file mode 100644
> index 000000000000..19ef775e8e5e
> --- /dev/null
> +++ b/include/uapi/linux/openat2.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_LINUX_OPENAT2_H
> +#define _UAPI_LINUX_OPENAT2_H
I think you should include the relevant header for __align_u64
etc. here.
[…]
> + * Arguments for how openat2(2) should open the target path. If @resolve is
> + * zero, then openat2(2) operates very similarly to openat(2).
> + *
> + * However, unlike openat(2), unknown bits in @flags result in -EINVAL rather
> + * than being silently ignored. @mode must be zero unless one of {O_CREAT,
> + * O_TMPFILE} are set.
> + *
> + * @flags: O_* flags.
> + * @mode: O_CREAT/O_TMPFILE file mode.
> + * @resolve: RESOLVE_* flags.
> + */
> +struct open_how {
> + __aligned_u64 flags;
> + __u16 mode;
> + __u16 __padding[3]; /* must be zeroed */
> + __aligned_u64 resolve;
> +};
> +
> +#define OPEN_HOW_SIZE_VER0 24 /* sizeof first published struct */
> +#define OPEN_HOW_SIZE_LATEST OPEN_HOW_SIZE_VER0
Are these really useful for the UAPI header? Is there a situation where
OPEN_HOW_SIZE_LATEST would be different from sizeof (struct open_how)?
The header is not compatible with the assembler anyway, so the numeric
constant does not seem useful.
Thanks,
Florian