[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191219134525.mgzmjbsp4wo5b2bw@yavin.dot.cyphar.com>
Date: Fri, 20 Dec 2019 00:45:25 +1100
From: Aleksa Sarai <cyphar@...har.com>
To: Florian Weimer <fweimer@...hat.com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
Jeff Layton <jlayton@...nel.org>,
"J. Bruce Fields" <bfields@...ldses.org>,
Shuah Khan <shuah@...nel.org>,
David Laight <david.laight@...lab.com>,
Christian Brauner <christian.brauner@...ntu.com>,
dev@...ncontainers.org, containers@...ts.linux-foundation.org,
libc-alpha@...rceware.org, linux-api@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 1/2] uapi: split openat2(2) definitions from fcntl.h
On 2019-12-19, Florian Weimer <fweimer@...hat.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).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists