On Wed, Jul 22, 2026 at 12:47 PM Miklos Szeredi <[email protected]> wrote: > > On Mon, 20 Jul 2026 at 12:07, Amir Goldstein <[email protected]> wrote: > > > It's not about this ioctl, it's about infrastructure reuse. > > It's about the fact that there is NOTHING special about dax_devlist; > > and no reason not to manage it via backing_files_map. > > > > The reason you stated was that you want userspace to determine the > > daxdev_index/backing_id - fine, no problem - this is why I asked that > > you pass it the desired backing_id in the ioctl. > > In fact I think that all fuse backing_ids would be better assigned by user > > space > > so the extension of padding => backing_id is not unique to famfs. > > Right, so I suggest to just reuse FUSE_DEV_IOC_BACKING_OPEN and add > two flags: one to enable user supplied backing ID and the other to > indicate that fd refers to DAX device. The changes to do compared to > the current patchset are quite minimal. > > > And the best part is that this request requires no changes to your > > userspace. > > You already bite the bullet and maintain the new/old uapi but changing the > > kernel implementation does not require this burden from you, so to be honest > > I really don't understand why you did not follow Miklos' suggestion. > > Code reuse is also important, but I understand John's position to want > to separate famfs from existing codebase as much as possible. And > because this is an implementation detail I don't want to make this a > show stopper. We can easily fix it later. > > > > - Lose the famfs interleaved extent format. I have complied with this > > > request. > > > It makes some things worse, but we'll discuss that later. > > > > > > > I am really not aware of a request to lose the interleaved extent format. > > How can this patch [2] from Miklos which reimplements this format as a > > generic > > uapi be mistaken for a request to lose this format? > > Let's not care. We can easily add this later if famfs (or any other > use case) decides to want this after all. > > Making the initial patchset smaller is win in any case. > > > Let me recap the former review requests as I understand them: > > > > 1. Use ioctl instead of GET_DAXDEV > > This is done, just need to reuse the existing ioctl instead of add a > new one with the same semantics (okay not true because of the fixed > backing ID extension...) > > > 2. Use backing files infra for daxdev table > > Leave this later. > > > 3. Use ioctl instead of GET_FMAP > > Not sure we agreed to use an ioctl for extent mapping. What we did > agree on was to use a generic interface that doesn't have anything > famfs specific in it.
My bad. I thought that FUSE_DEV_IOC_STRIPE_OPEN was an example of how GET_FMAP should be made into a generic interface. Sorry for the misunderstanding John. Thanks, Amir.
