On 2020-03-13, Al Viro [off-list ref] wrote:

On Fri, Mar 13, 2020 at 08:59:01PM +1100, Aleksa Sarai wrote:

quoted

On 2020-03-12, Stefan Metzmacher [off-list ref] wrote:

quoted

Am 12.03.20 um 17:24 schrieb Linus Torvalds:

quoted

But yes, if we have a major package like samba use it, then by all
means let's add linkat2(). How many things are we talking about? We
have a number of system calls that do *not* take flags, but do do
pathname walking. I'm thinking things like "mkdirat()"?)

I haven't looked them up in detail yet.
Jeremy can you provide a list?

Do you think we could route some of them like mkdirat() and mknodat()
via openat2() instead of creating new syscalls?

I have heard some folks asking for a way to create a directory and get a
handle to it atomically -- so arguably this is something that could be
inside openat2()'s feature set (O_MKDIR?). But I'm not sure how popular
of an idea this is.

For fuck sake, *NO*!

We don't need any more multiplexors from hell.  mkdir() and open() have
deeply different interpretation of pathnames (and anyone who asks for
e.g. traversals of dangling symlinks on mkdir() is insane).  Don't try to
mix those; even O_TMPFILE had been a mistake.

I agree that O_TMPFILE is a mess, and you're right that it wouldn't be a
good idea to fold it into open*(). But what is your opinion on a
hypothetical mkdirat2() which would let you get an fd to the directory
that was just created?

We really don't need openat2() turning into another one.  Syscall table
slots are not in a short supply, and the level of review one gets from
"new syscall added" is higher than from "make fubar(2) recognize a new
member in options->union_full_of_crap if it has RESOLVE_TO_WANK_WITH_RIGHT_HAND
set in options->flags, affecting its behaviour in some odd ways".
Which is a good thing, damnit.

You're quite right, and I don't intend openat2() to become another
ioctl-but-with-even-more-fun-semantics.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>