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. 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. Regards, Jason
