On 5/19/22 20:16, Miklos Szeredi wrote:
On Thu, 19 May 2022 at 19:42, Bernd Schubert <bschubert@xxxxxxx> wrote:
Can you help me a bit to understand what we should change? I had also
already thought to merge CREATE_EXT and OPEN_ATOMIC - so agreed.
Shall we make the other cases more visible?
Make it clear in the code flow if we are using the new request or the
old; e.g. rename current fuse_atomic_open() to fuse_open_nonatomic()
and do
static int fuse_open_atomic(...)
{
...
args.opcode = FUSE_OPEN_ATOMIC;
...
err = fuse_simple_request(...);
if (err == -ENOSYS)
goto fallback;
...
fallback:
return fuse_open_nonatomic();
}
static int fuse_atomic_open(...)
{
if (fc->no_open_atomic)
return fuse_open_nonatomic();
else
return fuse_open_atomic();
}
Also we can tweak fuse_dentry_revalidate() so it always invalidates
negative dentries if the new atomic open is available, and possibly
for positive dentries as well, if the rfc patch makes it.
Thank you, we will try to do it like that during the next day.
Thanks,
Bernd
