On Thu, 18 Aug 2022 09:05:24 -0300 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Wed, Aug 17, 2022 at 01:11:38PM -0300, Jason Gunthorpe wrote: > > dma-buf has become a way to safely acquire a handle to non-struct page > > memory that can still have lifetime controlled by the exporter. Notably > > RDMA can now import dma-buf FDs and build them into MRs which allows for > > PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory > > from PCI device BARs. > > > > This series supports a use case for SPDK where a NVMe device will be owned > > by SPDK through VFIO but interacting with a RDMA device. The RDMA device > > may directly access the NVMe CMB or directly manipulate the NVMe device's > > doorbell using PCI P2P. > > > > However, as a general mechanism, it can support many other scenarios with > > VFIO. I imagine this dmabuf approach to be usable by iommufd as well for > > generic and safe P2P mappings. > > > > This series goes after the "Break up ioctl dispatch functions to one > > function per ioctl" series. > > > > This is on github: https://github.com/jgunthorpe/linux/commits/vfio_dma_buf > > > > Jason Gunthorpe (4): > > dma-buf: Add dma_buf_try_get() > > vfio: Add vfio_device_get() > > vfio_pci: Do not open code pci_try_reset_function() > > vfio/pci: Allow MMIO regions to be exported through dma-buf > > > > drivers/vfio/pci/Makefile | 1 + > > drivers/vfio/pci/vfio_pci_config.c | 22 ++- > > drivers/vfio/pci/vfio_pci_core.c | 33 +++- > > drivers/vfio/pci/vfio_pci_dma_buf.c | 265 ++++++++++++++++++++++++++++ > > I forget about this.. > > Alex, do you want to start doing as Linus discused and I will rename > this new file to "dma_buf.c" ? > > Or keep this directory as having the vfio_pci_* prefix for > consistency? I have a hard time generating a strong opinion over file name redundancy relative to directory structure. By my count, over 17% of files in drivers/ have some file name redundancy to their parent directory structure (up to two levels). I see we already have two $FOO_dma_buf.c files in the tree, virtio and amdgpu among these. In the virtio case this is somewhat justified, to me at least, as the virtio_dma_buf.h file exists in a shared include namespace. However, this justification only accounts for about 1% of such files, for many others the redundancy exists in the include path as well. I guess if we don't have a reason other than naming consistency and accept an end goal to incrementally remove file name vs directory structure redundancy where it makes sense, sure, name it dma_buf.c. Ugh. Thanks, Alex
