From: Jeff Layton <jlayton@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>,
Chuck Lever <chuck.lever@oracle.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH v2 0/2] API for exporting connectable file handles to userspace
Date: Tue, 08 Oct 2024 07:07:03 -0400 [thread overview]
Message-ID: <021d3f9acf33ff74bfde7aadd6a9a01a8ee64248.camel@kernel.org> (raw)
In-Reply-To: <CAOQ4uxiBwtEs_weg67MHP4TOsXN7hVi0bDCUe_C7b2tHqohtAQ@mail.gmail.com>
On Mon, 2024-10-07 at 17:26 +0200, Amir Goldstein wrote:
> On Wed, Sep 25, 2024 at 11:14 AM Christian Brauner <brauner@kernel.org> wrote:
> >
> > > open_by_handle_at(2) does not have AT_ flags argument, but also, I find
> > > it more useful API that encoding a connectable file handle can mandate
> > > the resolving of a connected fd, without having to opt-in for a
> > > connected fd independently.
> >
> > This seems the best option to me too if this api is to be added.
>
> Thanks.
>
> Jeff, Chuck,
>
> Any thoughts on this?
>
Sorry for the delay. I think encoding the new flag into the fh itself
is a reasonable approach.
I'm less thrilled with using bitfields for this, just because I have a
general dislike of them, and they aren't implemented the same way on
all arches. Would it break ABI if we just turned the handle_type int
into two uint16_t's instead?
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2024-10-08 11:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-23 8:28 [PATCH v2 0/2] API for exporting connectable file handles to userspace Amir Goldstein
2024-09-23 8:28 ` [PATCH v2 1/2] fs: name_to_handle_at() support for "explicit connectable" file handles Amir Goldstein
2024-09-23 8:28 ` [PATCH v2 2/2] fs: open_by_handle_at() support for decoding " Amir Goldstein
2024-09-25 9:13 ` [PATCH v2 0/2] API for exporting connectable file handles to userspace Christian Brauner
2024-10-07 15:26 ` Amir Goldstein
2024-10-07 18:09 ` Chuck Lever III
2024-10-08 10:43 ` Amir Goldstein
2024-10-08 11:07 ` Jeff Layton [this message]
2024-10-08 13:11 ` Amir Goldstein
2024-10-08 13:43 ` Jeff Layton
2024-10-08 14:50 ` Amir Goldstein
2024-10-09 9:40 ` Jan Kara
2024-10-09 15:16 ` Amir Goldstein
2024-10-09 15:47 ` Amir Goldstein
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=021d3f9acf33ff74bfde7aadd6a9a01a8ee64248.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=cyphar@cyphar.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/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