Displaying 8 results from an estimated 8 matches for "vq_ctrl".
Did you mean:
req_ctrl
2019 Sep 26
1
[PATCH V2 6/8] mdev: introduce virtio device and its device ops
...39;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...
2019 Sep 25
3
[PATCH V2 6/8] mdev: introduce virtio device and its device ops
...*mdev, unsigned 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
2019 Sep 25
3
[PATCH V2 6/8] mdev: introduce virtio device and its device ops
...*mdev, unsigned 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
2019 Sep 25
0
[PATCH V2 6/8] mdev: introduce virtio device and its device ops
...ev_device *mdev);
>> +};
> 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'...
2019 Sep 25
2
[PATCH V2 6/8] mdev: introduce virtio device and its device ops
...el internal 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...
2019 Sep 25
2
[PATCH V2 6/8] mdev: introduce virtio device and its device ops
...el internal 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...
2019 Sep 24
17
[PATCH V2 0/8] mdev based hardware virtio offloading support
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
2019 Sep 24
17
[PATCH V2 0/8] mdev based hardware virtio offloading support
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