search for: device_ctrl

...e how stable above ops are. > > > It's the kernel internal API, so there's no strict requirement for this. > We will export a version value for userspace for compatibility. > > > > Does it make sense if defining > > just two callbacks here, e.g. vq_ctrl and device_ctrl, and then let the > > vendor driver to handle specific ops in each category (similar to how > > ioctl works)? > > > My understanding is that it introduce another indirection, you still > need to differ from different command, and it's less flexible than > direct cal...

...gned int offset, > + const void *buf, unsigned int len); > + int (*get_version)(struct mdev_device *mdev); > + u32 (*get_generation)(struct mdev_device *mdev); > +}; I'm not sure how stable above ops are. Does it make sense if defining just two callbacks here, e.g. vq_ctrl and device_ctrl, and then let the vendor driver to handle specific ops in each category (similar to how ioctl works)? Thanks Kevin

...gned int offset, > + const void *buf, unsigned int len); > + int (*get_version)(struct mdev_device *mdev); > + u32 (*get_generation)(struct mdev_device *mdev); > +}; I'm not sure how stable above ops are. Does it make sense if defining just two callbacks here, e.g. vq_ctrl and device_ctrl, and then let the vendor driver to handle specific ops in each category (similar to how ioctl works)? Thanks Kevin

...dev); >> +}; > I'm not sure how stable above ops are. It's the kernel internal API, so there's no strict requirement for this. We will export a version value for userspace for compatibility. > Does it make sense if defining > just two callbacks here, e.g. vq_ctrl and device_ctrl, and then let the > vendor driver to handle specific ops in each category (similar to how > ioctl works)? My understanding is that it introduce another indirection, you still need to differ from different command, and it's less flexible than direct callback. What's the value of d...

...API, so there's no strict requirement for this. We > will export a version value for userspace for compatibility. Given it's tied to virtio we probably want kernel+userspace feature bits? > > > Does it make sense if defining > > just two callbacks here, e.g. vq_ctrl and device_ctrl, and then let the > > vendor driver to handle specific ops in each category (similar to how > > ioctl works)? > > > My understanding is that it introduce another indirection, you still need to > differ from different command, and it's less flexible than direct callback...

...API, so there's no strict requirement for this. We > will export a version value for userspace for compatibility. Given it's tied to virtio we probably want kernel+userspace feature bits? > > > Does it make sense if defining > > just two callbacks here, e.g. vq_ctrl and device_ctrl, and then let the > > vendor driver to handle specific ops in each category (similar to how > > ioctl works)? > > > My understanding is that it introduce another indirection, you still need to > differ from different command, and it's less flexible than direct callback...

Hi all: There are hardware that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to

Hi all: There are hardware that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to