From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57475 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPcL0-0002Cg-5o for qemu-devel@nongnu.org; Fri, 18 Jun 2010 10:14:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPcKy-0007eZ-I3 for qemu-devel@nongnu.org; Fri, 18 Jun 2010 10:14:30 -0400 Received: from goliath.siemens.de ([192.35.17.28]:23230) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPcKy-0007eH-7J for qemu-devel@nongnu.org; Fri, 18 Jun 2010 10:14:28 -0400 Message-ID: <4C1B7F3A.8050109@siemens.com> Date: Fri, 18 Jun 2010 16:14:18 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() References: <20100614054923.879.33717.stgit@localhost.localdomain> <4C17492A.4050207@siemens.com> <201006151228.03533.paul@codesourcery.com> <1276635192.12015.901.camel@x201> <1276813540.3216.52.camel@x201> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: "chrisw@redhat.com" , "kvm@vger.kernel.org" , Paul Brook , "qemu-devel@nongnu.org" , Alex Williamson , "avi@redhat.com" , "kraxel@redhat.com" Markus Armbruster wrote: > Alex Williamson writes: > >> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote: >>> Alex Williamson writes: >>> >>>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote: >>>>>>> Alex proposed to disambiguate by adding "identified properties of the >>>>>>> immediate parent bus and device" to the path component. For PCI, these >>>>>>> are dev.fn. Likewise for any other bus where devices have unambigous >>>>>>> bus address. The driver name carries no information! >>>>>> From user POV, driver names are very handly to address a device >>>>>> intuitively - except for the case you have tones of devices on the same >>>>>> bus that are handled by the same driver. For that case we need to >>>>>> augment the device name with a useful per-bus ID, derived from the bus >>>>>> address where available, otherwise based on instance numbers. >>>>> This is where I think you're missing a trick. We don't need to augment the >>>>> name, we just need to allow the bus id to be used instead. >>>> For the case of a hot remove, I agree. If the user specifies "pci_del >>>> pci.0/03.0", that's completely sufficient because we don't care what's >>>> in that slot, just remove it. However, I still see some use cases for >>>> device names in the path. Take for example: >>>> >>>> (A): /i440FX-pcihost/pci.0/e1000.05.0 >>>> >>>> vs >>>> >>>> (B): /pci.0/05.0 >>>> >>>> (removing both the root bridge driver name and the device driver name) >>> / is the main system bus. System bus defines no bus address at the >>> moment. Therefore, you have to use the driver name i440FX-pcihost. >> So is the general rule "If a device's parent bus does not provide an >> address, print device name"? > > I think the general rule for constructing a *canonical* qdev path should > be: > > * If it's the main system bus, the path is /. > > * If it's another bus, the path is P/B, where P is the canonical path of > the device providing the bus, and B is the bus name. Unambiguous, > since no device ever defines two buses with the same name. > > * If it's a device, the path is P/D, where P is the canonical path of > the bus. If the bus defines bus addresses, then D is @A, where A is > the device's bus address. > > We haven't made up our minds whether the else case exists, or what to > do if it does. The simple "else D is the device model driver's name" > works only if the bus can't take multiple device models with the same > driver. ...which is already on x86 the case with multiple APICs or HPETs on the system bus. > > The canonical path is not the only path. For instance, a qdev ID is a > valid path, but it's not canonical. /i440FX-pcihost/pci.0/e1000 is > another valid, non-canonical path. Not only canonical paths need to be specified, also alias like the above. We should limit those alias to a required minimum ("required" means to me: improves human-friendliness compared to canonical form and preserves backward compatibility where relevant). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux