Re: [PATCH v2 03/13] iommufd: Rename IOMMUFD_OBJ_FAULT to IOMMUFD_OBJ_EVENTQ_IOPF

[Nicolin Chen <nicolinc@nvidia.com>]

On Wed, Dec 11, 2024 at 07:40:52AM +0000, Tian, Kevin wrote:
> > From: Nicolin Chen <nicolinc@nvidia.com>
> > Sent: Wednesday, December 4, 2024 6:10 AM
> > 
> > The fault object was designed exclusively for hwpt's IO page faults (PRI).
> > But its implementation can actually be reused for other purposes too, such
> > as hardware IRQ and event injections to user space.
> > 
> > Meanwhile, a fault object holds a list of faults. So it's more accurate to
> > call it a "fault queue". Combining the reusing idea above, a "fault queue"
> > can further rephrase to an "Event Queue for IOPF".
> > 
> > Rename the struct iommufd_fault to struct iommufd_eventq_iopf that holds
> > a
> > common Event Queue struct, similar to hwpt_paging holding a common
> > hwpt.
> > 
> > Roll out a minimal level of renamings to all the related functions.
> 
> could we keep iommufd_fault? Internally it will use the new eventq
> common struct but external facing names are all still around fault.
> the size of changed lines will be much smaller.
> 
> Then later for virq it could be iommufd_viommu_virq instead of
> iommufd_eventq_virq to explicitly draw its connection to viommu.
> 
> this is unlike hwpt where 'paging' or 'nested' is just decorative while
> 'fault' or 'virq' is noun on its own. 

It's a personal preference, though I don't have a strong opinion
about it. I can change them to iommufd_fault and iommufd_virq --
feels nicer to align with the other iommufd_v*: iommufd_vdevice,
iommufd_vqueue..

> > +static ssize_t iommufd_eventq_fops_read(struct file *filep, char __user *buf,
> > +					size_t count, loff_t *ppos)
> > +{
> > +	struct iommufd_eventq *eventq = filep->private_data;
> > +
> > +	if (!eventq->ops || !eventq->ops->read)
> > +		return -EOPNOTSUPP;
> > +	return eventq->ops->read(eventq, buf, count, ppos);
> > +}
> 
> the check on ops can be done in iommufd_eventq_init()

Ack. I think that's fine since we don't have a !ops->read case.

Thanks
Nic