Re: [PATCH] famfs: FUSE_GET_DAXDEV -> FUSE_DEV_IOC_BACKING_OPEN

[John Groves <john@groves.net>]

On 26/06/03 10:35AM, Miklos Szeredi wrote:
> On Tue, 2 Jun 2026 at 09:04, John Groves <john@groves.net> wrote:
> 
> > Device indices - the part that has to be right
> > ----------------------------------------------
> >
> > Everything below turns on what a famfs device index *is*, so let me make
> > it explicit, because the patch's model of it (kernel-allocated) isn't
> > workable for famfs.
> 
> The backing ID is a temporary reference for the lifetime of the fuse
> filesystem.  If there's a persistent device index the server just
> needs to map the persistent index to the temporary backing ID.
> 
> AFAICS the only case where this matters is debug messages, otherwise
> the kernel couldn't care less about whether the device index is
> persistent or not.
> 
> Am I missing something?
> 
> > Identity by reference, not by path - this part is right
> > -------------------------------------------------------
> >
> > The genuinely better idea here is getting the kernel out of resolving a
> > device pathname: the daemon hands over an already-resolved reference
> > (you do it with an fd, from which the kernel takes inode->i_rdev)
> > instead of a string the kernel has to kern_path(). I want to adopt that
> > - credit where it's due.
> 
> Name, dev_t  or fd are are all just ways to reference the same thing:
> the underlying DAX device.  They are completely interchangable, so if
> we have an interface that accepts one, there's no point in making it
> accept the others.
> 
> dev_t -> name:
>    readlink -f /dev/char/$dev
> 
> name -> dev_t:
>    stat -c %Hr:%Lr $name
> 
> name -> fd
>   fd = open(name, O_PATH);
> 
> fd -> dev_t
>   fstat(fd, &st);
> 
> Thanks,
> Miklos

Miklos,

Apologies for the slow response - I've been traveling and juggling the
other parts of my job. (If anyone here has only one job, don't tell me;
I'll just be jealous.)

I'm on vacation this week, but I plan to join the Thursday call -- from a
beach, signal permitting.

And starting next week I plan to take a real run at an implementation on
top of FUSE_DEV_IOC_BACKING_OPEN. So... beware ;)

Thanks,   
John