From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() Date: Tue, 15 Jun 2010 13:42:30 +0200 Message-ID: References: <20100614054923.879.33717.stgit@localhost.localdomain> <1276519930.12015.104.camel@x201> <201006141409.08653.paul@codesourcery.com> <4C17492A.4050207@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: chrisw@redhat.com, kraxel@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, Alex Williamson , avi@redhat.com, Paul Brook To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38477 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756995Ab0FOLmq (ORCPT ); Tue, 15 Jun 2010 07:42:46 -0400 In-Reply-To: <4C17492A.4050207@siemens.com> (Jan Kiszka's message of "Tue, 15 Jun 2010 11:34:34 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka writes: > Markus Armbruster wrote: >> Paul Brook writes: >> >>> Alex Williamson writes: >>> >>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote: >>>>> Could you explain why you add "identified properties of the immediate >>>>> parent bus and device"? They make the result ver much *not* a "dev >>>>> path" in the qdev sense... >>>> In order to try to get a unique string. Without looking into device >>>> properties, two e1000s would both be: >>>> >>>> /main-system-bus/pci.0/e1000 >>>> /main-system-bus/pci.0/e1000 >>>> >>>> Which is no better than simply "e1000" and would require us to fall back >>>> to instance ids again. The goal here is that anything that makes use of >>>> passing a dev when registering a vmstate gets an instance id of zero. >>> You already got the information you need, you just put it in the wrong place. >>> The canonical ID for the device could be its bus address. In practice we'd >>> probably want to allow the user to specify it by name, provided these are >>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would >>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we >>> can use an initial prefix to disambiguate a name/label from a bus address. >>> >>> For busses that don't have a consistent addressing scheme then some sort of >>> instance ID is unavoidable. I guess it may be possible to invent something >>> based on other device properties (e.g. address of the first IO port/memory >>> region). >> >> When that's inconvenient or impossible, we can still punt to user: make >> device ID mandatory. > > No option due to auto-created devices. And auto-generating IDs would > just create usability issues. Auto-generated IDs would become part of the ABI. Really so bad that it's "no option"? Mind, device ID becomes mandatory *only* for devices that don't have a useful bus address. We could even waive the ID requirement for the first device of a kind, i.e. require ID if and only if it's needed to disambiguate. >> We obviously need a way to unambigously name a device. It's okay to >> have multiple names for the same device. >> >> If the device has a device ID, that's an unambigous name. >> >> qdev paths may be ambigous when path components are resolved to driver >> names instead of IDs. >> >> 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. I'm not arguing against the use of driver names at all. >> 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. It's not either/or. Addressing by ID continues to work. Addressing by bus/driver-name continues to work. We merely add addressing by bus/@bus-address. >> 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. I object to @, because the part carries no information. Not the case for .. We still need a suitable definition of . Possible definitions: * n-th creation of a device. Drawbacks: depends on creation order. Relatively hard to maintain across migration. * n-th instance of a device. Drawback: changes on unplug. Good enough for interactive use, but it doesn't provide a stable device name. When counting devices either way, we can count per bus or globally. I prefer per bus. None of the above instance numbers are nearly as neat as bus addresses. >> 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. > > Jan From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46409 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOUXV-00080K-0V for qemu-devel@nongnu.org; Tue, 15 Jun 2010 07:42:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOUXT-0003Sj-Jw for qemu-devel@nongnu.org; Tue, 15 Jun 2010 07:42:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47058) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOUXT-0003Sa-Cp for qemu-devel@nongnu.org; Tue, 15 Jun 2010 07:42:43 -0400 From: Markus Armbruster Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() References: <20100614054923.879.33717.stgit@localhost.localdomain> <1276519930.12015.104.camel@x201> <201006141409.08653.paul@codesourcery.com> <4C17492A.4050207@siemens.com> Date: Tue, 15 Jun 2010 13:42:30 +0200 In-Reply-To: <4C17492A.4050207@siemens.com> (Jan Kiszka's message of "Tue, 15 Jun 2010 11:34:34 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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, Paul Brook , qemu-devel@nongnu.org, Alex Williamson , avi@redhat.com, kraxel@redhat.com Jan Kiszka writes: > Markus Armbruster wrote: >> Paul Brook writes: >> >>> Alex Williamson writes: >>> >>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote: >>>>> Could you explain why you add "identified properties of the immediate >>>>> parent bus and device"? They make the result ver much *not* a "dev >>>>> path" in the qdev sense... >>>> In order to try to get a unique string. Without looking into device >>>> properties, two e1000s would both be: >>>> >>>> /main-system-bus/pci.0/e1000 >>>> /main-system-bus/pci.0/e1000 >>>> >>>> Which is no better than simply "e1000" and would require us to fall back >>>> to instance ids again. The goal here is that anything that makes use of >>>> passing a dev when registering a vmstate gets an instance id of zero. >>> You already got the information you need, you just put it in the wrong place. >>> The canonical ID for the device could be its bus address. In practice we'd >>> probably want to allow the user to specify it by name, provided these are >>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would >>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we >>> can use an initial prefix to disambiguate a name/label from a bus address. >>> >>> For busses that don't have a consistent addressing scheme then some sort of >>> instance ID is unavoidable. I guess it may be possible to invent something >>> based on other device properties (e.g. address of the first IO port/memory >>> region). >> >> When that's inconvenient or impossible, we can still punt to user: make >> device ID mandatory. > > No option due to auto-created devices. And auto-generating IDs would > just create usability issues. Auto-generated IDs would become part of the ABI. Really so bad that it's "no option"? Mind, device ID becomes mandatory *only* for devices that don't have a useful bus address. We could even waive the ID requirement for the first device of a kind, i.e. require ID if and only if it's needed to disambiguate. >> We obviously need a way to unambigously name a device. It's okay to >> have multiple names for the same device. >> >> If the device has a device ID, that's an unambigous name. >> >> qdev paths may be ambigous when path components are resolved to driver >> names instead of IDs. >> >> 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. I'm not arguing against the use of driver names at all. >> 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. It's not either/or. Addressing by ID continues to work. Addressing by bus/driver-name continues to work. We merely add addressing by bus/@bus-address. >> 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. I object to @, because the part carries no information. Not the case for .. We still need a suitable definition of . Possible definitions: * n-th creation of a device. Drawbacks: depends on creation order. Relatively hard to maintain across migration. * n-th instance of a device. Drawback: changes on unplug. Good enough for interactive use, but it doesn't provide a stable device name. When counting devices either way, we can count per bus or globally. I prefer per bus. None of the above instance numbers are nearly as neat as bus addresses. >> 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. > > Jan