On Thu, Jun 17, 2021 at 12:12 AM Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> wrote: > > 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. > 1. keeping FDs across userspace restart 2. help save FD in the FUSE fd passthrough use case as implemented by Alessio Balsini > > 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 ? hmm, you are right. The open() callback cannot install FD from there. So in order for your use case to work, the VFS layer needs to be changed to transparently replace an empty file struct with another file struct that is prepared by the file system somewhere else. It is really beyond the current RFC patch's scope IMHO. Cheers, Tao Cheers, Tao -- Into Sth. Rich & Strange
