On Fri, Oct 30, 2020 at 12:23:25PM -0700, Raj, Ashok wrote: > On Fri, Oct 30, 2020 at 04:17:06PM -0300, Jason Gunthorpe wrote: > > On Fri, Oct 30, 2020 at 12:13:48PM -0700, Dave Jiang wrote: > > > > > > > > > On 10/30/2020 11:58 AM, Jason Gunthorpe wrote: > > > > On Fri, Oct 30, 2020 at 11:50:47AM -0700, Dave Jiang wrote: > > > > > .../ABI/stable/sysfs-driver-dma-idxd | 6 + > > > > > Documentation/driver-api/vfio/mdev-idxd.rst | 404 ++++++ > > > > > MAINTAINERS | 1 + > > > > > drivers/dma/Kconfig | 9 + > > > > > drivers/dma/idxd/Makefile | 2 + > > > > > drivers/dma/idxd/cdev.c | 6 +- > > > > > drivers/dma/idxd/device.c | 294 ++++- > > > > > drivers/dma/idxd/idxd.h | 67 +- > > > > > drivers/dma/idxd/init.c | 86 ++ > > > > > drivers/dma/idxd/irq.c | 6 +- > > > > > drivers/dma/idxd/mdev.c | 1121 +++++++++++++++++ > > > > > drivers/dma/idxd/mdev.h | 116 ++ > > > > > > > > Again, a subsytem driver belongs in the directory hierarchy of the > > > > subsystem, not in other random places. All this mdev stuff belongs > > > > under drivers/vfio > > > > > > Alex seems to have disagreed last time.... > > > https://lore.kernel.org/dmaengine/20200917113016.425dcde7@xxxxxxx/ > > > > Nobody else in the kernel is splitting subsystems up anymore > > > > > And I do agree with his perspective. The mdev is an extension of the PF > > > driver. It's a bit awkward to be a stand alone mdev driver under vfio/mdev/. > > > > By this logic we'd have giagantic drivers under drivers/ethernet > > touching netdev, rdma, scsi, vdpa, etc just because that is where the > > PF driver came from. > > What makes you think this is providing services like scsi/rdma/vdpa etc.. ? > > for DSA this playes the exact same role, not a different function > as you highlight above. these mdev's are creating DSA for virtualization > use. They aren't providing a completely different role or subsystem per-se. It is a different subsystem, different maintainer, and different reviewers. It is a development process problem, it doesn't matter what it is doing. Jason
