Re: [PATCH 04/10] vfio: Use a struct of function pointers instead of a many symbol_get()'s

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Apr 15, 2022 at 04:36:21PM +0200, Christoph Hellwig wrote:
> On Fri, Apr 15, 2022 at 09:13:01AM -0300, Jason Gunthorpe wrote:
> > > So I got anoyed at this as well a while ago and I still think this
> > > is the wrong way around.
> > 
> > What I plan to do in future is to have differnt ops returned depending
> > on if the file is a struct vfio_group or a struct vfio_device, so it
> > is not entirely pointless like this.
> 
> Uh, I think that is a rather ugly interface.  Why would kvm pass in
> FDs to both into the same interface.

We can do it either way, but IMHO, it is not very different than
passing a socket/file/pipe/etc FD to read() - the list of VFIO files
ops works identically on vfio device or vfio file FDs. The appeal to
multiplex at the file level means we don't need to build parallel
group/device uapi paths and parallel kAPI as well.

Ultimately none of these uses of the file care about what the file is,
these are all 'security proofs' and either FD type is fine to provide
the proof.

> Because that is the sensible layering - kvm already has an abstract
> interface for emulated devices.  So instead of doing symbol_get magic
> of some kind we should leverage it.

Hm, I don't know anthing about kvm's device interface
 
> But I can see how that is something you might not want to do for
> this series.  So maybe stick to the individual symbol_gets for now
> and I'll send a separate series to clean that up?  Especially as
> I have a half-finished series for that from a while ago anyway.

Sure, I only did this because I became sad while touching all the
symbol gets - it really is ugly. It will make the diffstat much worse,
but no problem.

If you have something already then lets avoid touching it too much
here.

Thanks,
Jason