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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
