[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e761b39b-79c7-40d4-947e-a209fcf2bb6b@ddn.com>
Date: Wed, 21 Jan 2026 20:03:32 +0100
From: Bernd Schubert <bschubert@....com>
To: Horst Birthelmer <horst@...thelmer.de>
Cc: Bernd Schubert <bernd@...ernd.com>, Luis Henriques <luis@...lia.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
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.
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?
Thanks,
Bernd
Powered by blists - more mailing lists