qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: RFC qdev path semantics


From: Jan Kiszka
Subject: [Qemu-devel] Re: RFC qdev path semantics
Date: Wed, 16 Jun 2010 14:01:24 +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:
>> Markus Armbruster wrote:
>>> A number of changes to qdev paths have been proposed in various threads.
>>> It's becoming harder to keep track of them, so let me sum them up in one
>>> place.  Please correct me if I misrepresent your ideas.
>>>
>>> I'm going to describe the current state of things, and the proposed
>>> changes (marked with ###).
>>>
>>>
>>> The device tree has the main system bus as root.  A child of a bus is a
>>> device.  A child of a device is a bus.
>>>
>>> A qdev path consists of qdev path components separated by '/'.  It
>>> resolves to a node in the device tree, either bus or device.
>>>
>>> The qdev path "/" resolves to the root, i.e. the main system bus.
>> Another aspect: A path may start with an arbitrary bus name, not only
>> the system bus. Although this is ambiguous, we need to keep it for
>> addressing the bus itself due to existing client use. But, IMO, we
>> should at least start deprecating this for addressing elements below
>> that bus (e.g. "pci.0/e1000").
> 
> I think this would be better served by adding explicit aliases/IDs for those 
> use-cases. i.e. define the global ID "pci.0" to be an alias for
>  /i440FX-pcihost/pci

Makes sense. We could attach this ID to the BusState (corresponding to
DeviceState:id) and manually set it during machine init.
qbus_find_recursive would then look for a matching ID instead of a name.

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]