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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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