From: Josh Triplett <josh@joshtriplett.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>,
io-uring@vger.kernel.org,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>, Jens Axboe <axboe@kernel.dk>,
Aleksa Sarai <cyphar@cyphar.com>,
linux-man <linux-man@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH v5 2/3] fs: openat2: Extend open_how to allow userspace-selected fds
Date: Thu, 23 Apr 2020 01:06:44 -0700 [thread overview]
Message-ID: <20200423080644.GA171696@localhost> (raw)
In-Reply-To: <CAJfpegtXj4bSbhpx+=z=R0_ZT8uPEJAAev0O+DVg3AX242e=-g@mail.gmail.com>
On Thu, Apr 23, 2020 at 09:45:45AM +0200, Miklos Szeredi wrote:
> On Thu, Apr 23, 2020 at 9:33 AM Josh Triplett <josh@joshtriplett.org> wrote:
> > > What are the plans for those syscalls that don't easily lend
> > > themselves to this modification (such as accept(2))?
> >
> > accept4 has a flags argument with more flags available, so it'd be
> > entirely possible to cleanly extend it further without introducing a new
> > version.
>
> Variable argument syscalls, you are thinking?
That or repurposing an existing pointer-sized argument as an
open_how-style struct, yes. But in any case, I'm not proposing that; I'm
proposing changes to the existing highly extensible openat2 syscall.
> > > I mean, you could open the file descriptor outside of io_uring in such
> > > cases, no?
> >
> > I would prefer to not introduce that limitation in the first place, and
> > instead open normal file descriptors.
> >
> > > The point of O_SPECIFIC_FD is to be able to perform short
> > > sequences of open/dosomething/close without having to block and having
> > > to issue separate syscalls.
> >
> > "close" is not a required component. It's entirely possible to use
> > io_uring to open a file descriptor, do various things with it, and then
> > leave it open for subsequent usage via either other io_uring chains or
> > standalone syscalls.
>
> If this use case arraises,
This wasn't a hypothetical "someone might want this". I'm stating that
this is a requirement I'm seeking to meet with this patch series, and
one I intend to use. The primary use case is interoperability with
other code using file descriptors and not using io_uring.
next prev parent reply other threads:[~2020-04-23 8:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 5:19 [PATCH v5 0/3] Support userspace-selected fds Josh Triplett
2020-04-22 5:19 ` [PATCH v5 1/3] fs: Support setting a minimum fd for "lowest available fd" allocation Josh Triplett
2020-04-22 6:06 ` Michael Kerrisk (man-pages)
2020-04-23 1:12 ` Dmitry V. Levin
2020-04-23 4:51 ` Josh Triplett
2020-04-23 9:24 ` Arnd Bergmann
2020-04-22 5:20 ` [PATCH v5 2/3] fs: openat2: Extend open_how to allow userspace-selected fds Josh Triplett
2020-04-22 6:06 ` Michael Kerrisk (man-pages)
2020-04-22 7:55 ` Miklos Szeredi
2020-04-23 0:48 ` Josh Triplett
2020-04-23 4:24 ` Miklos Szeredi
2020-04-23 4:42 ` Josh Triplett
2020-04-23 6:04 ` Miklos Szeredi
2020-04-23 7:33 ` Josh Triplett
2020-04-23 7:45 ` Miklos Szeredi
2020-04-23 7:57 ` Miklos Szeredi
2020-04-23 9:20 ` Miklos Szeredi
2020-04-23 9:46 ` Miklos Szeredi
2020-04-23 8:06 ` Josh Triplett [this message]
2020-04-22 5:20 ` [PATCH v5 3/3] fs: pipe2: Support O_SPECIFIC_FD Josh Triplett
2020-04-22 6:06 ` Michael Kerrisk (man-pages)
2020-04-22 15:44 ` Florian Weimer
2020-04-23 0:44 ` Josh Triplett
2020-04-22 6:05 ` [PATCH v5 0/3] Support userspace-selected fds Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200423080644.GA171696@localhost \
--to=josh@joshtriplett.org \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=cyphar@cyphar.com \
--cc=io-uring@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mtk.manpages@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.