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. John, can you please also look at review comments provided by Sashiko? Thanks, Miklos
