From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJxHF-0000oj-LB for qemu-devel@nongnu.org; Thu, 25 Jun 2009 18:18:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJxHB-0000cX-3e for qemu-devel@nongnu.org; Thu, 25 Jun 2009 18:18:41 -0400 Received: from [199.232.76.173] (port=40003 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJxHA-0000c3-Pb for qemu-devel@nongnu.org; Thu, 25 Jun 2009 18:18:36 -0400 Received: from mx20.gnu.org ([199.232.41.8]:23204) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJxHA-0003SW-GJ for qemu-devel@nongnu.org; Thu, 25 Jun 2009 18:18:36 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJxH9-0005na-RG for qemu-devel@nongnu.org; Thu, 25 Jun 2009 18:18:36 -0400 From: Paul Brook Subject: Re: [Qemu-devel] drive_add vs. pci_add Date: Thu, 25 Jun 2009 23:18:32 +0100 References: <4A431D3D.2040604@web.de> <200906251702.44505.paul@codesourcery.com> <4A43C1D8.1000100@codemonkey.ws> In-Reply-To: <4A43C1D8.1000100@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906252318.33211.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Jan Kiszka , Avi Kivity On Thursday 25 June 2009, Anthony Liguori wrote: > Paul Brook wrote: > > On Thursday 25 June 2009, Avi Kivity wrote: > >> On 06/25/2009 09:46 AM, Jan Kiszka wrote: > >>> Hi, > >>> > >>> sorry, it's still early, but isn't the monitor command 'drive_add' > >>> completely redundant to 'pci_add ... storage'? If yes, and drive_add is > >>> only there for legacy users, I would mask its help from the monitor > >>> interface to avoid confusion. > >> > >> What we really want is pci_add storage to add a storage controller, and > >> drive_add to attach a drive to that controller. I don't think that's > >> what happens now. > > > > Part of the problem is that we don't currently isolate configs for > > different pats of the device stack. There are several different layers at > > which hotplug can occur: > > > > - Device - e.g. PCI hotplug. If done properly this shouldn't care whether > > you're adding a NIC, VGA, SCSI HBA, or whatever. > > - Drive - Adding/removing drives to an existing HBA. > > - Media - e.g. changing the contents of a CDROM drive. > > Also, we probably want to separate the definition of storage from the > act of connecting the storage via hotplug. If I were going to add new > monitor commands today, I may do something like: I'm not sure about the exact sequences you describe, but yes, this is the sort of thing I'm getting at. The exact details need a fair amount of consideration, we want to make sure we're not working around creating things at the wrong time. For example, you should not be connection SCSI drives to an LSI HBA, you should be connecting them to the scsi bus provided by that device. Paul