[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6ba16bf8-8e8a-343a-335d-ab77d7cda195@redhat.com>
Date: Thu, 26 Sep 2019 16:12:07 +0800
From: Jason Wang <jasowang@...hat.com>
To: "Tian, Kevin" <kevin.tian@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
"intel-gvt-dev@...ts.freedesktop.org"
<intel-gvt-dev@...ts.freedesktop.org>,
"kwankhede@...dia.com" <kwankhede@...dia.com>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"mst@...hat.com" <mst@...hat.com>,
"Bie, Tiwei" <tiwei.bie@...el.com>
Cc: "christophe.de.dinechin@...il.com" <christophe.de.dinechin@...il.com>,
"sebott@...ux.ibm.com" <sebott@...ux.ibm.com>,
"airlied@...ux.ie" <airlied@...ux.ie>,
"joonas.lahtinen@...ux.intel.com" <joonas.lahtinen@...ux.intel.com>,
"heiko.carstens@...ibm.com" <heiko.carstens@...ibm.com>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"rob.miller@...adcom.com" <rob.miller@...adcom.com>,
"lulu@...hat.com" <lulu@...hat.com>,
"eperezma@...hat.com" <eperezma@...hat.com>,
"pasic@...ux.ibm.com" <pasic@...ux.ibm.com>,
"borntraeger@...ibm.com" <borntraeger@...ibm.com>,
"haotian.wang@...ive.com" <haotian.wang@...ive.com>,
"Wang, Zhi A" <zhi.a.wang@...el.com>,
"farman@...ux.ibm.com" <farman@...ux.ibm.com>,
"idos@...lanox.com" <idos@...lanox.com>,
"gor@...ux.ibm.com" <gor@...ux.ibm.com>,
"Liang, Cunming" <cunming.liang@...el.com>,
"zhenyuw@...ux.intel.com" <zhenyuw@...ux.intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@...el.com>,
"Wang, Xiao W" <xiao.w.wang@...el.com>,
"freude@...ux.ibm.com" <freude@...ux.ibm.com>,
"jani.nikula@...ux.intel.com" <jani.nikula@...ux.intel.com>,
"parav@...lanox.com" <parav@...lanox.com>,
"Wang, Zhihong" <zhihong.wang@...el.com>,
"akrowiak@...ux.ibm.com" <akrowiak@...ux.ibm.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"cohuck@...hat.com" <cohuck@...hat.com>,
"oberpar@...ux.ibm.com" <oberpar@...ux.ibm.com>,
"maxime.coquelin@...hat.com" <maxime.coquelin@...hat.com>,
"daniel@...ll.ch" <daniel@...ll.ch>,
"Zhu, Lingshan" <lingshan.zhu@...el.com>
Subject: Re: [PATCH V2 6/8] mdev: introduce virtio device and its device ops
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
Powered by blists - more mailing lists