[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
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 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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 <driver>[@<bus-address>|.<instance-no>]. 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
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), (continued)
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Markus Armbruster, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(),
Jan Kiszka <=
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Markus Armbruster, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/15