Re: [PATCH V2 6/8] mdev: introduce virtio device and its device ops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2019/9/26 上午8:48, Tian, Kevin wrote:
+};
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 doing this?

I just thought doing so may provide better compatibility to the
parent driver. Even when new op is introduced, a parent driver
that was developed against the old set can still be loaded in the
new kernel. It just returns error when unrecognized ops are
routed through vq_ctrl and device_ctrl, if the userspace doesn't
favor the exposed version value. But if above ops set is pretty
stable, then this comment can be ignored.


This is really good point, we should keep it stable as a real transport. And when there's major changes, we should advertise through version then we can provide a new set of functions.

Thanks



Thanks
Kevin
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux