On 2019-12-19, Florian Weimer fweimer@redhat.com wrote:
- 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.
Right -- no idea why I forgot to include them.
[…]
- 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.
OPEN_HOW_SIZE_VER0 could conceivably be useful (in the future we may do size-based checks) but maybe we can just expose it if someone actually ends up needing it.
I will move them to the in-kernel header (we use them for BUILD_BUG_ONs to make sure that the sizes are correct).