From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44960) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBS38-0002dj-84 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 11:06:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBS31-0000z9-Rz for qemu-devel@nongnu.org; Tue, 11 Sep 2012 11:06:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBS31-0000yz-Ia for qemu-devel@nongnu.org; Tue, 11 Sep 2012 11:06:43 -0400 Date: Tue, 11 Sep 2012 18:07:57 +0300 From: "Michael S. Tsirkin" Message-ID: <20120911150757.GA26666@redhat.com> References: <1347000499-28701-1-git-send-email-nab@linux-iscsi.org> <1347000499-28701-5-git-send-email-nab@linux-iscsi.org> <504A1A32.5050705@redhat.com> <20120908224032.GC20588@redhat.com> <504D85D6.2090703@redhat.com> <20120910062437.GD16819@redhat.com> <504F40BA.7020800@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <504F40BA.7020800@us.ibm.com> Subject: Re: [Qemu-devel] [PATCH 4/5] virtio-scsi: Add start/stop functionality for vhost-scsi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , kvm-devel , Jan Kiszka , Zhi Yong Wu , qemu-devel , "Nicholas A. Bellinger" , lf-virt , Anthony Liguori , target-devel , Hannes Reinecke , Paolo Bonzini , Zhi Yong Wu , Christoph Hellwig On Tue, Sep 11, 2012 at 08:46:34AM -0500, Anthony Liguori wrote: > On 09/10/2012 01:24 AM, Michael S. Tsirkin wrote: > >On Mon, Sep 10, 2012 at 08:16:54AM +0200, Paolo Bonzini wrote: > >>Il 09/09/2012 00:40, Michael S. Tsirkin ha scritto: > >>>On Fri, Sep 07, 2012 at 06:00:50PM +0200, Paolo Bonzini wrote: > >>>>Il 07/09/2012 08:48, Nicholas A. Bellinger ha scritto: > >>>>>Cc: Stefan Hajnoczi > >>>>>Cc: Zhi Yong Wu > >>>>>Cc: Michael S. Tsirkin > >>>>>Cc: Paolo Bonzini > >>>>>Signed-off-by: Nicholas Bellinger > >>>>>--- > >>>>> hw/virtio-pci.c | 2 ++ > >>>>> hw/virtio-scsi.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ > >>>>> hw/virtio-scsi.h | 1 + > >>>>> 3 files changed, 52 insertions(+), 0 deletions(-) > >>>> > >>>>Please create a completely separate device vhost-scsi-pci instead (or > >>>>virtio-scsi-tcm-pci, or something like that). It is used completely > >>>>differently from virtio-scsi-pci, it does not make sense to conflate the > >>>>two. > >>> > >>>Ideally the name would say how it is different, not what backend it > >>>uses. Any good suggestions? > >> > >>I chose the backend name because, ideally, there would be no other > >>difference. QEMU _could_ implement all the goodies in vhost-scsi (such > >>as reservations or ALUA), it just doesn't do that yet. > >> > >>Paolo > > > >Then why do you say "It is used completely differently from > >virtio-scsi-pci"? Isn't it just a different backend? > > > >If yes then it should be a backend option, like it is > >for virtio-net. > > I don't mean to bike shed here so don't take this as a nack on > making it a backend option, but in retrospect, the way we did > vhost-net was a mistake even though I strongly advocated for it to > be a backend option. > > The code to do it is really, really ugly. I think it would have > made a lot more sense to just make it a device and then have it not > use a netdev backend or any other kind of backend split. > > For instance: > > qemu -device vhost-net-pci,tapfd=X > > I know this breaks the model of separate backends and frontends but > since vhost-net absolutely requires a tap fd, I think it's better in > the long run to not abuse the netdev backend to prevent user > confusion. Having a dedicated backend type that only has one > possible option and can only be used by one device is a bit silly > too. > > So I would be in favor of dropping/squashing 3/5 and radically > simplifying how this was exposed to the user. > > I would just take qemu_vhost_scsi_opts and make them device properties. > > Regards, > > Anthony Liguori I'd like to clarify that I'm fine with either approach. Even a separate device is OK if this is what others want though I like it the least. > >