RE: [PATCH RFC v2 00/13] IOMMUFD Generic interface

Tian, Kevin
2022-09-21T03:40:55Z

> From: Jason Gunthorpe <jgg@nvidia.com>
> 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.