On 8/21/24 17:03, Miklos Szeredi wrote:
> On Wed, 21 Aug 2024 at 16:44, Bernd Schubert <bernd.schubert@xxxxxxxxxxx> wrote:
>
>> struct atomic_open
>> {
>> uint64_t atomic_open_flags;
>> struct fuse_open_out open_out;
>> uint8_t future_padding1[16];
>> struct fuse_entry_out entry_out;
>> uint8_t future_padding2[16];
>> }
>>
>>
>> What do you think?
>
> I'm wondering if something like the "compound procedure" in NFSv4
> would work for fuse as well?
I need to figure out how that actually works in NFS.
Do you have a suggestion how to bundle open + getattr in one request
with compounds? My thinking is that we need something like
#define MAX_OPS 8 // abitrary value
#define MAX_OP_OUT_SZ
struct op {
uint32_t opcode;
uint32_t arg_sz;
void *arg;
};
struct fuse_compound
{
uint32_t n_ops;
struct op ops[MAX_OPS];
}
But how would fuse_file_open() know how to send a sequence of requests?
I don't see an issue to decode that on the server side into multiple
requests, but how do we process the result in fuse-client? For fg
requests we have exactly request that gets processed by the vfs
operaration sending a request - how would that look like with compounds?
Or do I totally misunderstand you and you want to use compounds to avoid
the uber struct for atomic-open? At least we still need to add in the
ATOMIC_OPEN_IS_OPEN_GETATTR flag there and actually another like
ATOMIC_OPEN_IS_DIRECTORY.
Thanks,
Bernd
