On 2022-07-05 10:12, Christoph Hellwig wrote: > On Tue, Jul 05, 2022 at 10:51:02AM -0300, Jason Gunthorpe wrote: >>> In fact I'm not even sure this should be a character device, it seems >>> to fit it way better with the PCI sysfs hierchacy, just like how we >>> map MMIO resources, which these are anyway. And once it is on sysfs >>> we do have a uniqueue inode and need none of the pseudofs stuff, and >>> don't need all the glue code in nvme either. >> >> Shouldn't there be an allocator here? It feels a bit weird that the >> entire CMB is given to a single process, it is a sharable resource, >> isn't it? > > Making the entire area given by the device to the p2p allocator available > to user space seems sensible to me. That is what the current series does, > and what a sysfs interface would do as well. Yes, I think Jason is assuming the sysfs file would behave like the existing mmio resource files where the process doing the mapping specifies the offset and length into the BAR. That is not what we want here, but I don't see why I don't see why we can't do the same thing in sysfs as we do with the char device with a bin_attribute->mmap() callback. mmapping the char device was convenient in user space, but it's not much more work to dig through sysfs and mmap an attribute from there. Using sysfs means we don't need all the messy callbacks from the nvme driver, which is a plus. But I'm not sure how we'd get or unmap the mapping of a sysfs file or avoid the anonymous inode. Seems with the existing PCI resources, it uses an bin_attribute->f_mapping() callback to pass back the iomem_get_mapping() mapping on file open. revoke_iomem() is then used to nuke the VMAs. I don't think we can use the same infrastructure here as that would add a dependency on CONFIG_IO_STRICT_DEVMEM; which would be odd. And I'm not sure whether there is a better way. Logan
