> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, September 21, 2022 4:08 AM > > On Tue, Sep 13, 2022 at 02:05:13AM +0000, Tian, Kevin wrote: > > A side open is about the maintenance model of iommufd. > > > > This series proposes to put its files under drivers/iommu/, while the > > logic is relatively self-contained compared to other files in that directory. > > > > Joerg, do you plan to do same level of review on this series as you did > > for other iommu patches or prefer to a lighter model with trust on the > > existing reviewers in this area (mostly VFIO folks, moving forward also > > include vdpa, uacces, etc.)? > > From my view, I don't get the sense the Joerg is interested in > maintaining this, so I was expecting to have to PR this to Linus on > its own (with the VFIO bits) and a new group would carry it through > the initial phases. I'm fine with this model if it also matches Joerg's thought. Then we need add a "X: drivers/iommu/iommufd" line under IOMMU SUBSYSTEM in the MAINTAINERS file. > > However, I'm completely dead set against repeating past mistakes of > merging half-finished code through one tree expecting some other tree > will finish the work. > > This means new features like, say, dirty tracking, will need to come > in one unit with: the iommufd uAPI, any new iommu_domain ops/api, at > least one driver implementation and a functional selftest. > > Which means we will need to put in some work to avoid/manage > conflicts inside the iommu drivers. > Completely agree.
