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
