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 15:00:23 +0200 Message-ID: <4C177967.3000700@siemens.com> References: <20100614054923.879.33717.stgit@localhost.localdomain> <201006151304.17342.paul@codesourcery.com> <4C176F03.1010805@siemens.com> <201006151339.23356.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , "chrisw@redhat.com" , "kvm@vger.kernel.org" , Markus Armbruster , Alex Williamson , "avi@redhat.com" , "kraxel@redhat.com" To: Paul Brook Return-path: Received: from david.siemens.de ([192.35.17.14]:24546 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754680Ab0FONAu (ORCPT ); Tue, 15 Jun 2010 09:00:50 -0400 In-Reply-To: <201006151339.23356.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: Paul Brook wrote: >> Paul Brook wrote: >>>>>> 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? >>> Autocompletion can report all of them. >> Autocompletion can only provide what is later on parseable. > > Of course. > >> It doesn't >> help to see "e1000" and "03.0" as device addresses because you do not >> know their relation that way. Only combining the information into a >> single name does. > > I don't get your argument here. Why shouldn't e1000 and @03.0 refer to the > same device? Querying the device itself will tell you both, so it's not hard > to figure out that they refer to the same thing. Either piece of information > is sufficient, so why do we require both? To avoid having to issue an "info qtree" in the middle of an auto-completion for some other command. > > Note that autocompletion and enumeration for mechanical traversal are > different problems. The former should include useful aliases for humans (i.e. > both e1000 and @03.0). The latter should be limited to the unique values > corresponding to canonical addresses (i.e. @03.0). > >>>> 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. >>> I don't think either of these are intuitive. There's a good chance that >>> isa-serial.0 will not correspond to the first serial port in the guest. >> Only if you start tweaking the base addresses. Then it will still >> correspond to the addition order AND the user should be aware of this >> special setup. > > I'm pretty sure there are some machines that have both internal UARTs > (considered to be the primary ports), and secondary ports on an ISA bus. > > If you really want instance numbers, then they may make most sense appended to > the driver name. However I think this should be independent of bus addressing, > and bus addresses make most sense as the canonical address. That's how my current implementation looks like. > >>> Much better would be allowing use of IO port or MMIO addresses to >>> identify ISA devices. Some modification to the ISABus code may be >>> required to implement this. >> Works for serial, but fails for ISA devices not occupying an address. > > An ISA device without an IO/MMIO capabilities seems extremely unlikely. What > exactly would such a device do? Inject interrupts via that bus (while exposing registers in some other way). The m48t59 seems to fall in this category (unless I'm missing something ATM). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux