[Intel-gfx] [PATCH V2 6/8] mdev: introduce virtio device and its device ops

[Jason Wang]

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