Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932237AbZICUbC (ORCPT ); Thu, 3 Sep 2009 16:31:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932186AbZICUbB (ORCPT ); Thu, 3 Sep 2009 16:31:01 -0400 Received: from smtp-outbound-1.vmware.com ([65.115.85.69]:34752 "EHLO smtp-outbound-1.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932144AbZICUbA (ORCPT ); Thu, 3 Sep 2009 16:31:00 -0400 From: Dmitry Torokhov Organization: VMware, Inc. To: James Bottomley Subject: Re: [PATCH] SCSI driver for VMware's virtual HBA. Date: Thu, 3 Sep 2009 13:31:02 -0700 User-Agent: KMail/1.12.0 (Linux/2.6.31-rc8; KDE/4.3.0; x86_64; ; ) Cc: Alok Kataria , Matthew Wilcox , Roland Dreier , Bart Van Assche , Robert Love , Randy Dunlap , Mike Christie , "linux-scsi@vger.kernel.org" , LKML , Andrew Morton , Rolf Eike Beer , Maxime Austruy References: <1251415060.16297.58.camel@ank32.eng.vmware.com> <1251911789.23106.25.camel@ank32.eng.vmware.com> <1252008182.3941.61.camel@mulgrave.site> In-Reply-To: <1252008182.3941.61.camel@mulgrave.site> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909031331.03037.dtor@vmware.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1755 Lines: 34 On Thursday 03 September 2009 01:03:02 pm James Bottomley wrote: > > > > > > I'm not really asking you to standardise anything (yet). I was more > > > probing for why you hadn't included any of the SCSI control plane > > > interfaces and what lead you do produce a different design from the > > > current patterns in virtual I/O. I think what I'm hearing is "Because > > > we didn't look at how modern SCSI drivers are constructed" and "Because > > > we didn't look at how virtual I/O is currently done in Linux". That's > > > OK (it's depressingly familiar in drivers), > > > > I am sorry that's not the case, the reason we have different design as I > > have mentioned above is because we want a generic mechanism which works > > for all/most of the GOS's out their and doesn't need to be specific to > > Linux. > > Slightly confused now ... you're saying you did look at the transport > class and virtio? But you chose not to do a virtio like interface (for > reasons which I'm still not clear on) ... Virtio is Linux-specific and is not available on older kernels which our hypervisor/PVSCSI combination does support. Even if we were to use virtio-like schema in the hypervisor code we would have to re-implement much of the virtio code for kernels earlier than those shipped in '07 and do the same for other operating systems for no apparent benefit. The PCI device abstraction is self-contained and works well on Windows, Linux and other guest operating systems and so it was chosen. -- Dmitry -- 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/