>> I've already recommended that iopmem not be a block
>> instead be a device-dax instance. I also don't think it should claim
>> the PCI ID, rather the driver that wants to map one of its bars this
>> way can register the memory region with the device-dax core.
>> I'm not sure there are enough device drivers that want to do this to
>> have it be a generic /sys/.../resource_dmableX capability. It still
>> seems to be an exotic one-off type of configuration.
> Yes, this is essentially my thinking. Except I think the userspace
> interface should really depend on the device itself. Device dax is a
> good choice for many and I agree the block device approach wouldn't be
I tend to agree here. The block device interface has seen quite a bit of
resistance and /dev/dax looks like a better approach for most. We can look
at doing it that way in v2.
> Specifically for NVME CMB: I think it would make a lot of sense to just
> hand out these mappings with an mmap call on /dev/nvmeX. I expect CMB
> buffers would be volatile and thus you wouldn't need to keep track of
> where in the BAR the region came from. Thus, the mmap call would just be
> an allocator from BAR memory. If device-dax were used, userspace would
> need to lookup which device-dax instance corresponds to which nvme
I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
device-dax instance under the nvme device, or if you already have the nvme
sysfs path the dax instance(s) will appear under the "dax" sub-directory.
Personally I think mapping the dax resource in the sysfs tree is a nice
way to do this and a bit more intuitive than mapping a /dev/nvmeX.