[PATCH v3 15/15] vfio: Add struct device to vfio_device

Tian, Kevin kevin.tian at intel.com
Thu Sep 22 05:18:34 UTC 2022


> From: Jason Gunthorpe <jgg at ziepe.ca>
> Sent: Thursday, September 22, 2022 12:10 AM
> 
> On Tue, Sep 20, 2022 at 10:55:40PM +0000, Tian, Kevin wrote:
> > > From: Alex Williamson <alex.williamson at redhat.com>
> > > Sent: Wednesday, September 21, 2022 4:27 AM
> > >
> > > On Fri,  9 Sep 2022 18:22:47 +0800
> > > Kevin Tian <kevin.tian at intel.com> wrote:
> > >
> > > > From: Yi Liu <yi.l.liu at intel.com>
> > > >
> > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the
> > > > sysfs path of the parent, indicating the device is bound to a vfio
> > > > driver, e.g.:
> > > >
> > > > /sys/devices/pci0000\:6f/0000\:6f\:01.0/vfio-dev/vfio0
> > > >
> > > > It is also a preparatory step toward adding cdev for supporting future
> > > > device-oriented uAPI.
> > > >
> > > > Add Documentation/ABI/testing/sysfs-devices-vfio-dev.
> > > >
> > > > Also take this chance to rename chardev 'vfio' to 'vfio-group' in
> > > > /proc/devices.
> > >
> > > What's the risk/reward here, is this just more aesthetically pleasing
> > > symmetry vs 'vfio-dev'?  The char major number to name association in
> > > /proc/devices seems pretty obscure, but what due diligence have we
> done
> > > to make sure this doesn't break anyone?  Thanks,
> >
> > I'm not sure whether the content of /proc/devices is considered as ABI.
> >
> > @Jason?
> 
> Ah, I've forgotten why we got here - didn't we have a naming conflict
> with the new stuff that is being introduced?

No, we don't have. There is no new char dev introduced in this series.

Later when device cdev is added a new device major will be allocated for
'vfio-dev'. It's at that time renaming existing 'vfio' to 'vfio-group' is probably
clearer, which is what I understood from your earlier suggestion.

> 
> ABI wise it is not a problem unless there is a real user, I'm not
> aware of anything scanning /proc, that has been obsoleted by sysfs a
> long time ago.
> 

This is a good news.


More information about the dri-devel mailing list