search for: dev_ops

...> The contents of the ops structure is essentially defined by the id, which is > > why I was leaning towards them being defined together. They are effectively > > interlocked, the id defines which mdev "endpoint" > > driver is loaded and that driver requires mdev_get_dev_ops() to return the > > structure required by the driver. I wish there was a way we could > > incorporate type checking here. We toyed with the idea of having the class > > in the same structure as the ops, but I think this approach was chosen for > > simplicity. We could sti...

...ed by the > > > > > > id, which is why I was leaning towards them being defined together. > > > > > > They are effectively interlocked, the id defines which mdev "endpoint" > > > > > > driver is loaded and that driver requires mdev_get_dev_ops() to > > > > > > return the structure required by the driver. I wish there was a > > > > > > way we could incorporate type checking here. We toyed with the > > > > > > idea of having the class in the same structure as the ops, but I > >...

...to be paired with ids in id_table in mdev_driver > +structure for probing the correct driver. "The class id (specified in id) is used to match a device with an mdev driver via its id table." ? > The device_ops is device > +specific callbacks which can be get through mdev_get_dev_ops() > +function by mdev bus driver. "The device specific callbacks (specified in *ops) are obtainable via mdev_get_dev_ops() (for use by the mdev bus driver.)" ? > For vfio-mdev device, its device specific > +ops are as follows: "A vfio-mdev device (class id MDEV_ID_VFIO)...

...to be paired with ids in id_table in mdev_driver > +structure for probing the correct driver. "The class id (specified in id) is used to match a device with an mdev driver via its id table." ? > The device_ops is device > +specific callbacks which can be get through mdev_get_dev_ops() > +function by mdev bus driver. "The device specific callbacks (specified in *ops) are obtainable via mdev_get_dev_ops() (for use by the mdev bus driver.)" ? > For vfio-mdev device, its device specific > +ops are as follows: "A vfio-mdev device (class id MDEV_ID_VFIO)...

...structure is essentially defined by the id, > > > > which is why I was leaning towards them being defined together. > > > > They are effectively interlocked, the id defines which mdev "endpoint" > > > > driver is loaded and that driver requires mdev_get_dev_ops() to > > > > return the structure required by the driver. I wish there was a way > > > > we could incorporate type checking here. We toyed with the idea of > > > > having the class in the same structure as the ops, but I think this > > > > approach...

...ucture is essentially defined by the id, >>>>> which is why I was leaning towards them being defined together. >>>>> They are effectively interlocked, the id defines which mdev "endpoint" >>>>> driver is loaded and that driver requires mdev_get_dev_ops() to >>>>> return the structure required by the driver. I wish there was a way >>>>> we could incorporate type checking here. We toyed with the idea of >>>>> having the class in the same structure as the ops, but I think this >>>>> appro...

...ucture is essentially defined by the id, >>>>> which is why I was leaning towards them being defined together. >>>>> They are effectively interlocked, the id defines which mdev "endpoint" >>>>> driver is loaded and that driver requires mdev_get_dev_ops() to >>>>> return the structure required by the driver. I wish there was a way >>>>> we could incorporate type checking here. We toyed with the idea of >>>>> having the class in the same structure as the ops, but I think this >>>>> appro...

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others