Re: [PATCH RFC] fuse: add generic file store

["Enrico Weigelt, metux IT consult" <lkml@metux.net>]

On 16.06.21 12:20, Peng Tao wrote:
>> So, just open() a file on a fuse fs can't restore the fd directly
>> (instead of opening a new file) ? If that's the case, that would mean,
>> userland has to take very special actions in order to get it. Right ?
> Yes.

Then, it's not at all what I'm looking for :(

> Oh, nop, that is not how the current RFC works. I see two gaps:
> 1. /dev/fuse is not accessible to all processes by default

it shouldn't necessary at all - in my use case.

> 2. open() syscall doesn't take enough arguments to tell the kernel
> which file's fd it wants.

open() only works on a path name - that's exactly what I need.

Could you please tell more what your use case is actually about ?
Still struggling what you're actually going to achieve.

Just keeping fd's open while a server restarts ?
If that's what you want, I see much wider use far outside of fuse,
and that might call for some more generic approach - something like
Plan9's /srv filesystem.

> It seems that a proper solution to your use case is to:
> 1. extend the open() syscall to take a flag like FOPEN_FUSE_OPEN_FD (I
> agree it's a bad name;)

But that would still require changes in my userland. Something I do not
want per definition - it should work transparently. The application just
knows some file name (it might be even expecting common device names,
but put inside its own mount ns), nothing more, and no need to change
the application itself.

> 2. FUSE kernel passes such a flag to fuse daemon
> 3. FUSE userspace daemon opens the file in the underlying file system,
> store it to a kernel FD store, then return its IDR in the reply to
> FUSE_OPEN API
> 4. FUSE kernel looks up underlying FD with the IDR, install it in the
> calling process FD table, and return the new FD to the application

Does FUSE actually manipulate the process' fd table directly, while
in the open() callback ?


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287