From: Horst Birthelmer <horst@birthelmer.de>
To: Luis Henriques <luis@igalia.com>
Cc: Bernd Schubert <bschubert@ddn.com>,
Bernd Schubert <bernd@bsbernd.com>,
Amir Goldstein <amir73il@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>,
"Darrick J. Wong" <djwong@kernel.org>,
Kevin Chen <kchen@ddn.com>,
Horst Birthelmer <hbirthelmer@ddn.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Matt Harvey <mharvey@jumptrading.com>,
"kernel-dev@igalia.com" <kernel-dev@igalia.com>
Subject: Re: Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation
Date: Thu, 22 Jan 2026 11:59:41 +0100 [thread overview]
Message-ID: <aXICIREIL46NcaK8@fedora.fritz.box> (raw)
In-Reply-To: <87ldhp7wbf.fsf@wotan.olymp>
On Thu, Jan 22, 2026 at 10:53:24AM +0000, Luis Henriques wrote:
> On Thu, Jan 22 2026, Horst Birthelmer wrote:
...
> >>
> >> So, to summarise:
> >>
> >> In the end, even FUSE servers that do support compound operations will
> >> need to check the operations within a request, and act accordingly. There
> >> will be new combinations that will not be possible to be handle by servers
> >> in a generic way: they'll need to return -EOPNOTSUPP if the combination of
> >> operations is unknown. libfuse may then be able to support the
> >> serialisation of that specific operation compound. But that'll require
> >> flagging the request as "serialisable".
> >
> > OK, so this boils down to libfuse trying a bit harder than it does at the moment.
> > After it calls the compound handler it should check for EOPNOTSUP and the flag
> > and then execute the single requests itself.
> >
> > At the moment the fuse server implementation itself has to do this.
> > Actually the patched passthrough_hp does exactly that.
> >
> > I think I can live with that.
>
> Well, I was trying to suggest to have, at least for now, as little changes
> to libfuse as possible. Something like this:
>
> if (req->se->op.compound)
> req->se->op.compound(req, arg->count, arg->flags, in_payload);
> else if (arg->flags & FUSE_COMPOUND_SERIALISABLE)
> fuse_execute_compound_sequential(req);
> else
> fuse_reply_err(req, ENOSYS);
>
> Eventually, support for specific non-serialisable operations could be
> added, but that would have to be done for each individual compound.
> Obviously, the server itself could also try to serialise the individual
> operations in the compound handle, and use the same helper.
>
Is there a specific reason why you want that change in lowlevel.c?
The patched passthrouhg_hp does this implicitly, actually without the flag.
It handles what it knows as 'atomic' compound and uses the helper for the rest.
If you don't want to handle specific combinations, just check for them
and return an error.
> Cheers,
> --
> Luís
next prev parent reply other threads:[~2026-01-22 10:59 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 18:12 [RFC PATCH v2 0/6] fuse: LOOKUP_HANDLE operation Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 1/6] fuse: store index of the variable length argument Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 2/6] fuse: move fuse_entry_out structs out of the stack Luis Henriques
2025-12-15 14:03 ` Bernd Schubert
2025-12-16 10:30 ` Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 3/6] fuse: initial infrastructure for FUSE_LOOKUP_HANDLE support Luis Henriques
2025-12-15 13:36 ` Bernd Schubert
2025-12-15 17:06 ` Amir Goldstein
2025-12-15 17:11 ` Bernd Schubert
2025-12-15 18:09 ` Amir Goldstein
2025-12-15 18:23 ` Bernd Schubert
2025-12-16 10:36 ` Luis Henriques
2025-12-16 10:19 ` Miklos Szeredi
2025-12-16 11:33 ` Luis Henriques
2025-12-16 11:46 ` Miklos Szeredi
2025-12-16 12:02 ` Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation Luis Henriques
2025-12-15 17:39 ` Bernd Schubert
2025-12-16 11:48 ` Luis Henriques
2025-12-17 10:18 ` Amir Goldstein
2025-12-17 14:45 ` Luis Henriques
2025-12-17 15:02 ` Bernd Schubert
2025-12-17 16:53 ` Luis Henriques
2025-12-16 8:49 ` Joanne Koong
2025-12-16 8:54 ` Bernd Schubert
2025-12-17 0:32 ` Joanne Koong
2025-12-17 1:00 ` Darrick J. Wong
2025-12-17 2:48 ` Joanne Koong
2025-12-17 9:38 ` Luis Henriques
2025-12-17 10:08 ` Miklos Szeredi
2025-12-17 16:17 ` Luis Henriques
2025-12-16 10:39 ` Miklos Szeredi
2025-12-16 10:51 ` Amir Goldstein
2025-12-16 11:07 ` Miklos Szeredi
2026-01-09 11:57 ` Luis Henriques
2026-01-09 12:38 ` Miklos Szeredi
2026-01-09 14:45 ` Luis Henriques
2026-01-09 14:56 ` Horst Birthelmer
2026-01-09 17:07 ` Luis Henriques
2026-01-12 7:43 ` Horst Birthelmer
2026-01-09 15:20 ` Miklos Szeredi
2026-01-09 15:03 ` Amir Goldstein
2026-01-09 15:37 ` Miklos Szeredi
2026-01-09 15:56 ` Bernd Schubert
2026-01-09 16:28 ` Miklos Szeredi
2026-01-09 17:16 ` Luis Henriques
2026-01-09 18:29 ` Amir Goldstein
2026-01-09 19:01 ` Miklos Szeredi
2026-01-09 19:28 ` Amir Goldstein
2026-01-09 19:12 ` Bernd Schubert
2026-01-09 19:55 ` Horst Birthelmer
2026-01-21 17:56 ` Luis Henriques
2026-01-21 18:16 ` Horst Birthelmer
2026-01-21 18:28 ` Bernd Schubert
2026-01-21 18:36 ` Horst Birthelmer
2026-01-21 18:49 ` Bernd Schubert
2026-01-21 19:00 ` Horst Birthelmer
2026-01-21 19:03 ` Bernd Schubert
2026-01-21 19:12 ` Horst Birthelmer
2026-01-22 9:52 ` Luis Henriques
2026-01-22 10:20 ` Horst Birthelmer
2026-01-22 10:35 ` Bernd Schubert
2026-01-22 10:53 ` Luis Henriques
2026-01-22 10:59 ` Horst Birthelmer [this message]
2026-01-22 11:25 ` Luis Henriques
2026-01-22 11:32 ` Bernd Schubert
2026-01-22 12:34 ` Horst Birthelmer
2025-12-12 18:12 ` [RFC PATCH v2 5/6] fuse: factor out NFS export related code Luis Henriques
2025-12-14 15:13 ` Amir Goldstein
2025-12-15 12:05 ` Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 6/6] fuse: implementation of export_operations with FUSE_LOOKUP_HANDLE Luis Henriques
2025-12-16 10:58 ` Miklos Szeredi
2025-12-16 17:06 ` Luis Henriques
2025-12-16 20:12 ` Horst Birthelmer
2025-12-17 17:02 ` Luis Henriques
2025-12-17 18:02 ` Horst Birthelmer
2025-12-16 11:01 ` Amir Goldstein
2025-12-16 17:26 ` Luis Henriques
2025-12-14 17:02 ` [RFC PATCH v2 0/6] fuse: LOOKUP_HANDLE operation Askar Safin
2025-12-15 12:08 ` Luis Henriques
2025-12-16 0:33 ` Askar Safin
2025-12-16 17:36 ` Luis Henriques
2025-12-16 18:49 ` Bernd Schubert
2025-12-16 22:45 ` Askar Safin
2025-12-25 7:42 ` Askar Safin
2026-01-04 22:38 ` Askar Safin
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=aXICIREIL46NcaK8@fedora.fritz.box \
--to=horst@birthelmer.de \
--cc=amir73il@gmail.com \
--cc=bernd@bsbernd.com \
--cc=bschubert@ddn.com \
--cc=djwong@kernel.org \
--cc=hbirthelmer@ddn.com \
--cc=kchen@ddn.com \
--cc=kernel-dev@igalia.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luis@igalia.com \
--cc=mharvey@jumptrading.com \
--cc=miklos@szeredi.hu \
/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