From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:60708 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726252AbfIZIMx (ORCPT ); Thu, 26 Sep 2019 04:12:53 -0400 Subject: Re: [PATCH V2 6/8] mdev: introduce virtio device and its device ops References: <20190924135332.14160-1-jasowang@redhat.com> <20190924135332.14160-7-jasowang@redhat.com> <2210d23d-38e4-e654-e53d-7867348de86a@redhat.com> From: Jason Wang Message-ID: <6ba16bf8-8e8a-343a-335d-ab77d7cda195@redhat.com> Date: Thu, 26 Sep 2019 16:12:07 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-s390-owner@vger.kernel.org List-ID: To: "Tian, Kevin" , "kvm@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "intel-gfx@lists.freedesktop.org" , "intel-gvt-dev@lists.freedesktop.org" , "kwankhede@nvidia.com" , "alex.williamson@redhat.com" , "mst@redhat.com" , "Bie, Tiwei" Cc: "christophe.de.dinechin@gmail.com" , "sebott@linux.ibm.com" , "airlied@linux.ie" , "joonas.lahtinen@linux.intel.com" , "heiko.carstens@de.ibm.com" , "virtualization@lists.linux-foundation.org" , "rob.miller@broadcom.com" , "lulu@redhat.com" , "eperezma@redhat.com" , "pasic@linux.ibm.com" , "borntraeger@de.ibm.com" , "haotian.wang@sifive.com" , "Wang, Zhi A" , "farman@linux.ibm.com" , "idos@mellanox.com" , "gor@linux.ibm.com" , "Liang, Cunming" , "zhenyuw@linux.intel.com" , "Vivi, Rodrigo" , "Wang, Xiao W" , "freude@linux.ibm.com" , "jani.nikula@linux.intel.com" , "parav@mellanox.com" , "Wang, Zhihong" , "akrowiak@linux.ibm.com" , "netdev@vger.kernel.org" , "cohuck@redhat.com" , "oberpar@linux.ibm.com" , "maxime.coquelin@redhat.com" , "daniel@ffwll.ch" , "Zhu, Lingshan" 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