[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: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() |
Date: |
Tue, 15 Jun 2010 15:07:53 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Jan Kiszka <address@hidden> writes:
> Markus Armbruster wrote:
>> Jan Kiszka <address@hidden> writes:
>>
>>> Markus Armbruster wrote:
>>>> Paul Brook <address@hidden> writes:
>>>>
>>>>> Alex Williamson <address@hidden> 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.
>
> IDs are there to find devices the user (or a higher level tool) passed
> to QEMU, qtree paths allow to locate _every_ device in a VM, and that in
> a well-organized hierarchy. That allows to explore and address a qtree
> element at the same time.
>
>>
>>>> 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.
>
> The format I will propose is "global-ID|/absolute/path", no more
> /path/global-ID as this comes with the risk of ambiguity (ID may shadow
> bus-local name of a device).
Doesn't this break existing usage?
We have a rule to resolve any ambiguity added by ID: it always takes
precedence over driver name. What path/ID does add is shadowing: it can
make a device inaccessible by driver name. Not much of a difference to
adding a second device with the same driver name.
>>>> 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.
>>
>> I object to <driver>@<bus-address>, because the <driver> part carries no
>> information.
>
> I does for a human being as bus addresses tend to be unreadable and can
> easily be confused, hence the additional, sometimes redundant driver name.
I *strenuously* object to making the driver name mandatory with
bus-address addressing.
If you think the human user needs to be protected from mistakes by
making him supply redundant information, then "device_del pci.0/04.0
e1000" is much better way than complicating device paths for human and
machine users alike, not to mention uses internal to QEMU.
>> Not the case for <driver>.<instance-no>. We still need a suitable
>> definition of <instance-no>. Possible definitions:
>>
>> * n-th creation of a <driver> device. Drawbacks: depends on creation
>> order. Relatively hard to maintain across migration.
>>
>> * n-th instance of a <driver> device. Drawback: changes on unplug.
>> Good enough for interactive use, but it doesn't provide a stable
>> device name.
>
> Every hotplug-capable bus must have a proper addressing scheme, I think
> this is a reasonable and achievable requirement. Then we don't need
> instance numbers for those buses.
What about USB?
>> When counting <driver> devices either way, we can count per bus or
>> globally. I prefer per bus.
>
> Yes, counting should be both per-driver and per-bus ("the <n>th device
> managed by <driver> on this bus").
Works for me.
>> None of the above instance numbers are nearly as neat as bus addresses.
>
> Right, wherever they are available.
>
> Jan
- 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(), Markus Armbruster, 2010/06/16
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/17
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/18
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/18
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/18
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Markus Armbruster, 2010/06/18
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/18
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/18
- 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(),
Markus Armbruster <=
- 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(), 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(), Markus Armbruster, 2010/06/16
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/14
[Qemu-devel] [RFC PATCH 2/5] savevm: Add DeviceState param, Alex Williamson, 2010/06/14
[Qemu-devel] [RFC PATCH 3/5] savevm: Make use of the new DeviceState param, Alex Williamson, 2010/06/14
[Qemu-devel] [RFC PATCH 4/5] eepro100: Add a dev field to eeprom new/free functions, Alex Williamson, 2010/06/14
[Qemu-devel] [RFC PATCH 5/5] virtio-net: Incorporate a DeviceState pointer and let savevm track instances, Alex Williamson, 2010/06/14
[Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string, Gerd Hoffmann, 2010/06/14