qemu-devel
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]