Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756012Ab2BLXlq (ORCPT ); Sun, 12 Feb 2012 18:41:46 -0500 Received: from ozlabs.org ([203.10.76.45]:33404 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755928Ab2BLXlo (ORCPT ); Sun, 12 Feb 2012 18:41:44 -0500 From: Rusty Russell To: James Bottomley , Paolo Bonzini Cc: Christian Hoff , BORNTRAE@linux.vnet.ibm.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, mst@redhat.com Subject: Re: Pe: [PATCH v5 1/3] virtio-scsi: first version In-Reply-To: <1329077777.21613.60.camel@dabdike.int.hansenpartnership.com> References: <4F30F4EE.4080607@redhat.com> <4F311154.9080407@de.ibm.com> <4F3119A0.7080005@redhat.com> <4F312492.1040002@de.ibm.com> <4F313526.2050907@redhat.com> <4F3390FB.80107@redhat.com> <1329077777.21613.60.camel@dabdike.int.hansenpartnership.com> User-Agent: Notmuch/0.6.1-1 (http://notmuchmail.org) Emacs/23.3.1 (i686-pc-linux-gnu) Date: Mon, 13 Feb 2012 10:11:03 +1030 Message-ID: <87vcnbd3hs.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1933 Lines: 42 On Sun, 12 Feb 2012 14:16:17 -0600, James Bottomley wrote: > On Thu, 2012-02-09 at 10:25 +0100, Paolo Bonzini wrote: > > On 02/08/2012 02:37 PM, Christian Hoff wrote: > > > Again, I have already done much testing with virtio-scsi and can confirm > > > that the code is working flawlessly. In my opinion, virtio-scsi is a > > > worthwhile addition to virtio-block and should be considered for inclusion > > > into mainline kernel code. > > > > Thank you very much! > > > > James, will you include virtio-scsi in 3.4? > > Well, no-one's yet answered the question I had about why. virtio-scsi > seems to be a basic duplication of virtio-blk except that it seems to > fix some problems virtio-blk has. Namely queue parameter discover, > which virtio-blk doesn't seem to do. There may also be a reason to cut > the stack lower down. Error handling is most often cited for this, but > no-one's satisfactorily explaned why it's better to do error handling in > the guest instead of the host. > > Could someone please explain to me why you can't simply fix virtio-blk? > Or would virtio-blk maintainers give a reason why they're unwilling to > have it fixed? My concern is simple: virtio_blk covers the 99% of cases, with very little complexity. To get that last 1%, we will end up re-specing much of SCSI. Having found someone who understand SCSI and is eager to maintain a driver and spec, I am deeply tempted to partition the problem as simple == virtio_blk, complex == virtio_scsi. In fact, it would allow us to tighten the spec on VIRTIO_BLK_T_SCSI_CMD to its actual use, which AFAICT is CDROMEJECT (maybe CDROMCLOSETRAY). Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/