On Sun, 12 Feb 2012 14:16:17 -0600, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
