From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() Date: Tue, 15 Jun 2010 13:45:14 +0200 Message-ID: <4C1767CA.1050809@siemens.com> References: <20100614054923.879.33717.stgit@localhost.localdomain> <4C17492A.4050207@siemens.com> <201006151228.03533.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Markus Armbruster , Alex Williamson , "chrisw@redhat.com" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "avi@redhat.com" , "kraxel@redhat.com" To: Paul Brook Return-path: Received: from goliath.siemens.de ([192.35.17.28]:22701 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757710Ab0FOLpc (ORCPT ); Tue, 15 Jun 2010 07:45:32 -0400 In-Reply-To: <201006151228.03533.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. I prefer having one name per device, both unique AND human-friendly. Adding yet another alias will solve only the first requirement. E.g., which one should I present to the monitor user when listing a bus for auto-completion or path error reporting? > >>> For other buses, we need to make something up. >>> >>> Note that addressing by bus address rather than name is generally >>> useful, not just in the context of savevm. For instance, I'd appreciate >>> being able to say something like "device_del pci.0/04.0". >> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump >> the bus first before you can identify which device you want to remove. > > We can allow both. > > A bus address is sufficient to uniquely identify a device. I see no reason to > require the driver name, or to include it in the canonical device address. Readability and simplicity (less aliases - for the same reason, I'm removing ID-based addresses from qtree paths, restricting them to the global, flat namespace). > >>> An easy way to get that is to reserve part of the name space for bus >>> addresses. If the path component starts with a letter, it's an ID or >>> driver name. If it starts with say '@', it's a bus address in >>> bus-specific syntax. The bus provides a method to look it up. >> I would prefer [@|.]. The former is >> set for buses that implement some to-be-defined device addressing >> service, the latter is the default on buses where that service is not >> available. > > If we have bus-address then I see no good reason to also add instance-no. > For busses that no natural address, we can define the address to be an > instance number. Again readability: isa-serial.0 & isa-serial.1 is more intuitive than isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA devices registered before them. > >>> That way, we gain a useful feature, and avoid having an savevm-specific >>> "device path" that isn't recognized anywhere else. >> Agreed, we should find one solution for all use cases. > > I wasn't aware that there was any suggestion of a separate savevm-specific > path. The whole point of a device path is to uniquely identify a device > within a machine. There may be many different paths that identify the same > device. When given a device and asked to generate path, the result should be > the canonical address. IMO this should be the least volatile, and avoid > redundant information. Given that it is also user-visible, it should also have an intuitive and informative format to avoid confusions. That may imply slightly more information than strictly required for machine-based processing. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux