From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60757 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOVkv-0000cz-GY for qemu-devel@nongnu.org; Tue, 15 Jun 2010 09:00:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOVkq-0001UI-77 for qemu-devel@nongnu.org; Tue, 15 Jun 2010 09:00:41 -0400 Received: from david.siemens.de ([192.35.17.14]:24400) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOVkp-0001RP-Uu for qemu-devel@nongnu.org; Tue, 15 Jun 2010 09:00:36 -0400 Message-ID: <4C177967.3000700@siemens.com> Date: Tue, 15 Jun 2010 15:00:23 +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> <201006151304.17342.paul@codesourcery.com> <4C176F03.1010805@siemens.com> <201006151339.23356.paul@codesourcery.com> In-Reply-To: <201006151339.23356.paul@codesourcery.com> 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: Paul Brook Cc: "chrisw@redhat.com" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , Markus Armbruster , Alex Williamson , "avi@redhat.com" , "kraxel@redhat.com" 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