From: Jeff Layton <[email protected]>
To: Jens Axboe <[email protected]>, Josh Triplett <[email protected]>
Cc: [email protected]
Subject: Re: [PATCHSET v2 0/6] Support selectable file descriptors
Date: Wed, 04 Mar 2020 14:28:18 -0500 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On Wed, 2020-03-04 at 12:10 -0700, Jens Axboe wrote:
> On 3/4/20 12:03 PM, Josh Triplett wrote:
> > On Wed, Mar 04, 2020 at 11:00:10AM -0700, Jens Axboe wrote:
> > > One of the fabled features with chains has long been the desire to
> > > support things like:
> > >
> > > <open fileX><read from fileX><close fileX>
> > >
> > > in a single chain. This currently doesn't work, since the read/close
> > > depends on what file descriptor we get on open.
> > >
> > > The original attempt at solving this provided a means to pass
> > > descriptors between chains in a link, this version takes a different
> > > route. Based on Josh's support for O_SPECIFIC_FD, we can instead control
> > > what fd value we're going to get out of open (or accept). With that in
> > > place, we don't need to do any magic to make this work. The above chain
> > > then becomes:
> > >
> > > <open fileX with fd Y><read from fd Y><close fd Y>
> > >
> > > which is a lot more useful, and allows any sort of weird chains without
> > > needing to nest "last open" file descriptors.
> > >
> > > Updated the test program to use this approach:
> > >
> > > https://git.kernel.dk/cgit/liburing/plain/test/orc.c?h=fd-select
> > >
> > > which forces the use of fd==89 for the open, and then uses that for the
> > > read and close.
> > >
> > > Outside of this adaptation, fixed a few bugs and cleaned things up.
> >
> > I posted one comment about an issue in patch 6.
> >
> > Patches 2-5 look great; for those:
> > Reviewed-by: Josh Triplett <[email protected]>
> >
> > Thanks for picking this up and running with it!
>
> Thanks for doing the prep work! I think it turned out that much better
> for it.
>
> Are you going to post your series for general review? I just stole
> your 1 patch that was needed for me.
>
This does seem like a better approach overall.
How should userland programs pick fds to use for this though? Should you
just start with some reasonably high number that you don't expect to
have been used by the current process or is there some more reliable way
to do it?
--
Jeff Layton <[email protected]>
next prev parent reply other threads:[~2020-03-04 19:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 18:00 [PATCHSET v2 0/6] Support selectable file descriptors Jens Axboe
2020-03-04 18:00 ` [PATCH 1/6] fs: openat2: Extend open_how to allow userspace-selected fds Jens Axboe
2020-03-04 18:00 ` [PATCH 2/6] io_uring: move CLOSE req->file checking into handler Jens Axboe
2020-03-04 18:00 ` [PATCH 3/6] io_uring: move read/write side file based prep into op handler Jens Axboe
2020-03-04 18:00 ` [PATCH 4/6] io_uring: support deferred retrival of file from fd Jens Axboe
2020-03-04 18:00 ` [PATCH 5/6] net: allow specific fd selection for __sys_accept4_file() Jens Axboe
2020-03-04 18:00 ` [PATCH 6/6] io_uring: allow specific fd for IORING_OP_ACCEPT Jens Axboe
2020-03-04 19:02 ` Josh Triplett
2020-03-04 19:09 ` Jens Axboe
2020-03-04 19:51 ` Josh Triplett
2020-03-04 19:03 ` [PATCHSET v2 0/6] Support selectable file descriptors Josh Triplett
2020-03-04 19:10 ` Jens Axboe
2020-03-04 19:28 ` Jeff Layton [this message]
2020-03-04 19:50 ` Jens Axboe
2020-03-04 19:56 ` Josh Triplett
2020-03-04 20:00 ` Jens Axboe
2020-03-04 20:09 ` Josh Triplett
2020-03-04 20:14 ` Jens Axboe
2020-03-09 20:33 ` Stefan Metzmacher
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=50d459bb4c894b99532d9f56fadceb0c317ab7f0.camel@kernel.org \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox