From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() Date: Tue, 15 Jun 2010 13:39:22 +0100 Message-ID: <201006151339.23356.paul@codesourcery.com> References: <20100614054923.879.33717.stgit@localhost.localdomain> <201006151304.17342.paul@codesourcery.com> <4C176F03.1010805@siemens.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: Jan Kiszka Return-path: Received: from mail.codesourcery.com ([38.113.113.100]:55159 "EHLO mail.codesourcery.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751156Ab0FOMj2 (ORCPT ); Tue, 15 Jun 2010 08:39:28 -0400 In-Reply-To: <4C176F03.1010805@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: > 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? 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. > > 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? Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35975 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOVQT-0001Et-Uv for qemu-devel@nongnu.org; Tue, 15 Jun 2010 08:39:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOVQO-00065j-UB for qemu-devel@nongnu.org; Tue, 15 Jun 2010 08:39:33 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:58656) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOVQO-00065O-MM for qemu-devel@nongnu.org; Tue, 15 Jun 2010 08:39:28 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() Date: Tue, 15 Jun 2010 13:39:22 +0100 References: <20100614054923.879.33717.stgit@localhost.localdomain> <201006151304.17342.paul@codesourcery.com> <4C176F03.1010805@siemens.com> In-Reply-To: <4C176F03.1010805@siemens.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006151339.23356.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka 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: > >>>> 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? 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. > > 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? Paul