Message-ID: <87pl726kko.fsf@wotan.olymp>
Date: Thu, 22 Jan 2026 09:52:23 +0000
From: Luis Henriques <luis@...lia.com>
To: Horst Birthelmer <horst@...thelmer.de>
Cc: Bernd Schubert <bschubert@....com>,  Bernd Schubert <bernd@...ernd.com>,
  Amir Goldstein <amir73il@...il.com>,  Miklos Szeredi <miklos@...redi.hu>,
  "Darrick J. Wong" <djwong@...nel.org>,  Kevin Chen <kchen@....com>,
  Horst Birthelmer <hbirthelmer@....com>,  "linux-fsdevel@...r.kernel.org"
 <linux-fsdevel@...r.kernel.org>,  "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>,  Matt Harvey <mharvey@...ptrading.com>,
  "kernel-dev@...lia.com" <kernel-dev@...lia.com>
Subject: Re: [RFC PATCH v2 4/6] fuse: implementation of the
 FUSE_LOOKUP_HANDLE operation

Hi!

On Wed, Jan 21 2026, Horst Birthelmer wrote:

> On Wed, Jan 21, 2026 at 08:03:32PM +0100, Bernd Schubert wrote:
>> 
>> 
>> On 1/21/26 20:00, Horst Birthelmer wrote:
>> > On Wed, Jan 21, 2026 at 07:49:25PM +0100, Bernd Schubert wrote:
>> >>
>> >>
>> > ...
>> >>> The problem Luis had was that he cannot construct the second request in the compound correctly
>> >>> since he does not have all the in parameters to write complete request.
>> >>
>> >> What I mean is, the auto-handler of libfuse could complete requests of
>> >> the 2nd compound request with those of the 1st request?
>> >>
>> > With a crazy bunch of flags, we could probably do it, yes.
>> > It is way easier that the fuse server treats certain compounds
>> > (combination of operations) as a single request and handles
>> > those accordingly.

Right, I think that at least the compound requests that can not be
serialised (i.e. those that can not be executed using the libfuse helper
function fuse_execute_compound_sequential()) should be flagged as such.
An extra flag to be set in the request should do the job.

This way, if this flag isn't set in a compound request and the FUSE server
doesn't have a compound handle, libfuse could serialise the requests.
Otherwise, it would return -ENOTSUPP.

>> Hmm, isn't the problem that each fuse server then needs to know those
>> common compound combinations? And that makes me wonder, what is the
>> difference to an op code then?
>
> I'm pretty sure we both have some examples and counter examples in mind.
>
> Let's implement a couple of the suggested compounds and we will see 
> if we can make generic rules. I'm not convinced yet, that we want to
> have a generic implementation in libfuse.
>
> The advantage to the 'add an opcode' for every combination 
> (and there are already a couple of those) approach is that
> you don't need more opcodes, so no changes to the kernel.
> You need some code in the fuse server, though, which to me is
> fine, since if you have atomic operations implemented there,
> why not actually use them.
>
> The big advantage is, choice.
>
> There will be some examples (like the one from Luis)
> where you don't actually have a generic choice,
> or you create some convention, like you just had in mind.
> (put the result of the first operation into the input
> of the next ... or into some fields ... etc.)

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".

Cheers,
-- 
Luís

Powered by blists - more mailing lists