[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 02/23] qdev: Restrict direct bus addressing v
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH v4 02/23] qdev: Restrict direct bus addressing via its name |
Date: |
Wed, 23 Jun 2010 13:24:05 +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:
>>
>>> From: Jan Kiszka <address@hidden>
>>>
>>> We allow to address a bus only using its local name. This is ambiguous
>>> but unfortunately so handy that people (specifically libvirt) will
>>> likely complain if bus=pci.0 needs to be replaced with
>>> bus=/i440FX-pcihost/pci.0 all over the place. So keep this for now but
>>> drop at least support for starting a qtree walks with an abbreviated bus
>>> name.
>>>
>>> Signed-off-by: Jan Kiszka <address@hidden>
>>
>> Again, affects only -device and device_add option bus.
>>
>> Before, an argument started either with '/' (path anchored at root) or a
>> bus name (path anchored at that bus).
>>
>> Now, an argument started either with '/' (path anchored at root) or it
>> is a bus name.
>>
>> If we decide to add sane relative paths to qdev, i.e. paths anchored at
>> unique ID, we get a slight anomaly here:
>>
>> bus=a bus name, not a relative path
>> bus=a/b relative path anchored at node with unique ID a.
>>
>> Works for me.
>
> If we allow ID-anchoring, we are in ambiguous land again unless we
> reject IDs that happen to match any bus name in the system. Even then,
> the problem will be that the aliases based on bus names need to be
> auto-generated (for backward compatibility) while IDs are user-assigned.
> If the user comes first, auto-generation will innocently produce an ugly
> conflict and we will either have to reject bus instantiation or live
> with the conflict.
No.
For backward compatibility, we need bus=a to be interpreted as bus name,
not as qdev path. In other words, we overload bus to be either bus name
or qdev path. It's a wart, but unavoidable unless we restrict bus to
bus names and add a separate option for paths.
As long as we require all qdev paths to be absolute, the wart is
relatively small. The rule to resolve the overloading is simple: if the
value starts with '/', then it's a qdev path, else it's a bus name.
With relative qdev paths, the wart becomes more a bit more prominent.
The rule to resolve the overloading becomes: if the value contains '/',
it's a qdev path, else it's a bus name.
I can't see ambiguity here.
- [Qemu-devel] [PATCH v4 03/23] qdev: Drop ID matching from qtree paths, (continued)
[Qemu-devel] [PATCH v4 06/23] qdev: Push QMP mode checks into qbus_list_bus/dev, Jan Kiszka, 2010/06/15
[Qemu-devel] [PATCH v4 05/23] qdev: Convert device and bus lists to QTAILQ, Jan Kiszka, 2010/06/15
[Qemu-devel] [PATCH v4 02/23] qdev: Restrict direct bus addressing via its name, Jan Kiszka, 2010/06/15
[Qemu-devel] [PATCH v4 08/23] qdev: Introduce qdev_iterate_recursive, Jan Kiszka, 2010/06/15
[Qemu-devel] [PATCH v4 07/23] qdev: Allow device specification by qtree path for device_del, Jan Kiszka, 2010/06/15
[Qemu-devel] [PATCH v4 09/23] monitor: Fix leakage during completion processing, Jan Kiszka, 2010/06/15
[Qemu-devel] [PATCH v4 10/23] monitor: Fix command completion vs. boolean switches, Jan Kiszka, 2010/06/15
[Qemu-devel] [PATCH v4 13/23] monitor: Allow to specify HMP-specifc command arguments, Jan Kiszka, 2010/06/15
[Qemu-devel] [PATCH v4 11/23] monitor: Add completion support for option lists, Jan Kiszka, 2010/06/15