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: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v4 02/23] qdev: Restrict direct bus addressing via its name
Date: Wed, 23 Jun 2010 12:17:10 +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

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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

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