On 4/29/22 13:09, Jason Gunthorpe wrote: > On Fri, Apr 29, 2022 at 11:54:16AM +0100, Joao Martins wrote: >> On 4/29/22 09:12, Tian, Kevin wrote: >>>> From: Joao Martins <joao.m.martins@xxxxxxxxxx> >>>> Sent: Friday, April 29, 2022 5:09 AM >>> [...] >>>> + >>>> +static int iommu_read_and_clear_dirty(struct iommu_domain *domain, >>>> + struct iommufd_dirty_data *bitmap) >>> >>> In a glance this function and all previous helpers doesn't rely on any >>> iommufd objects except that the new structures are named as >>> iommufd_xxx. >>> >>> I wonder whether moving all of them to the iommu layer would make >>> more sense here. >>> >> I suppose, instinctively, I was trying to make this tie to iommufd only, >> to avoid getting it called in cases we don't except when made as a generic >> exported kernel facility. >> >> (note: iommufd can be built as a module). > > Yeah, I think that is a reasonable reason to put iommufd only stuff in > iommufd.ko rather than bloat the static kernel. > > You could put it in a new .c file though so there is some logical > modularity? I can do that (iommu.c / dirty.c if no better idea comes to mind, suggestions welcome :)). Although I should said that there's some dependency on iopt structures and what not so I have to see if this is a change for the better. I'll respond here should it be dubious.
