Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754174AbZIARZ7 (ORCPT ); Tue, 1 Sep 2009 13:25:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753854AbZIARZ6 (ORCPT ); Tue, 1 Sep 2009 13:25:58 -0400 Received: from cantor.suse.de ([195.135.220.2]:47340 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753721AbZIARZ6 (ORCPT ); Tue, 1 Sep 2009 13:25:58 -0400 Subject: Re: [PATCH] SCSI driver for VMware's virtual HBA. From: James Bottomley To: akataria@vmware.com Cc: Dmitry Torokhov , 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 In-Reply-To: <1251824374.16169.128.camel@ank32.eng.vmware.com> References: <1251415060.16297.58.camel@ank32.eng.vmware.com> <20090901161651.GO22870@parisc-linux.org> <200909010933.50571.dtor@vmware.com> <1251823925.3864.216.camel@mulgrave.site> <1251824374.16169.128.camel@ank32.eng.vmware.com> Content-Type: text/plain Date: Tue, 01 Sep 2009 12:25:49 -0500 Message-Id: <1251825949.12482.34.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3022 Lines: 59 On Tue, 2009-09-01 at 09:59 -0700, Alok Kataria wrote: > On Tue, 2009-09-01 at 09:52 -0700, James Bottomley wrote: > > On Tue, 2009-09-01 at 09:33 -0700, Dmitry Torokhov wrote: > > > On Tuesday 01 September 2009 09:16:51 am Matthew Wilcox wrote: > > > > On Tue, Sep 01, 2009 at 09:12:43AM -0700, Roland Dreier wrote: > > > > > I'm not really sure we should be trying to force drivers to share just > > > > > because they are paravirtualized -- if there is real commonality, then > > > > > sure put it in common code, but different hypervisors are probably as > > > > > different as different hardware. > > > > > > > > I really disagree. This kind of virtualised drivers are pretty much > > > > communication protocols, and not hardware. As such, why design a new one? > > > > If there's an infelicity in the ibmvscsi protocol, it makes sense to > > > > design a new one. But being different for the sake of being different > > > > is just a way to generate a huge amount of make-work. > > > > > > > > > > The same thing can be said about pretty much anything. We don't have > > > single SCSI, network, etc driver handling every devices in their > > > respective class, I don't see why it would be different here. > > > A hypervisor presents the same interface to the guest OS (whether > > > it is Linux, Solaris or another OS) much like a piece of silicone > > > does and it may very well be different form other hypervisors. > > > > Nobody said you had to have the exact same driver for every hypervisor. > > What people are suggesting is that we look at commonalities in the > > interfaces both from a control plane point of view (transport class) and > > from a code sharing point of view (libscsivirt). However, all the > > hypervisor interfaces I've seen are basically DMA rings ... they really > > do seem to be very similar across hypervisors, so it does seem there > > could be a lot of shared commonality. I'm not going to insist on RDMA > > emulation, but perhaps you lot should agree on what a guest to > > hypervisor DMA interface looks like. > > Which is this other hypervisor driver that you are talking about, > ibmvscsi is using RDMA emulation and I don't think you mean that. lguest uses the sg_ring abstraction. Xen and KVM were certainly looking at this too. > And anyways how large is the DMA code that we are worrying about here ? > Only about 300-400 LOC ? I don't think we might want to over-design for > such small gains. So even if you have different DMA code, the remaining thousand or so lines would be in common. That's a worthwhile improvement. The benefit to users would be a common control plane and interface from the transport class, plus common code means more testers regardless of virtualisation technology chosen. James -- 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/