Re: [PATCH RFC 03/19] iommufd: Dirty tracking data support

Joao Martins
2022-04-29T14:33:44Z

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@oracle.com>
>>>> 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.