qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Plan for moving forward with QOM


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Thu, 15 Sep 2011 11:49:40 +0100

On Thu, Sep 15, 2011 at 7:31 AM, Gleb Natapov <address@hidden> wrote:
> On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
>> All device relationships are identified as named properties.  A QOM
>> path name
>> consists of a named device, followed by a series of properties which
>> may or may
>> not refer to other devices.  For instance, all of the following are
>> valid paths:
>>
>>  /i440fx/piix3/i8042/aux
>>  /i440fx/slot[1.0]/i8042/aux
>>  /i440fx/slot[1.0]/bus/piix3/i8042/aux
>>
> Have you looked at device paths generated by get_fw_dev_path() in qdev?
> This function generates Open Firmware device path. The difference
> between OF device path and the examples above is that OF device path has
> a meaning outside of QEMU and can be used by firmware to find a device
> a path refers too. Will QOM be able to generate them?
>
> The paths look like:
> /address@hidden/address@hidden,1/address@hidden/address@hidden
> /address@hidden/address@hidden/address@hidden/address@hidden
> /address@hidden/address@hidden/address@hidden/address@hidden
> /address@hidden/address@hidden,1/address@hidden/address@hidden
> /address@hidden/address@hidden,1/address@hidden/address@hidden
> /address@hidden/address@hidden/address@hidden,0
> /address@hidden/address@hidden/address@hidden
> /address@hidden/address@hidden/address@hidden
> /address@hidden/address@hidden,1/address@hidden/address@hidden
> /address@hidden/address@hidden/address@hidden/address@hidden/address@hidden
> /address@hidden/address@hidden,2/address@hidden/address@hidden
> /address@hidden/address@hidden,2/address@hidden/address@hidden/address@hidden
> /address@hidden/linuxboot.bin
>
> For isa machines:
> /isa/address@hidden/address@hidden/address@hidden
> /isa/address@hidden/address@hidden
> /isa/address@hidden/address@hidden
> /isa/address@hidden/address@hidden/address@hidden

Yes, it's not clear to me whether the OF device path will be
orthogonal to QOM or not.

Another part where I am not sure yet:
"Device names are completely independent of pathnames.  For devices that are no
user created, device names should be treated as opaque blobs with absolutely no
semantic meaning."

What does this mean?  Perhaps you're saying that:
create_object('rtl8139', 'my-nic')
pci_bus_name = resolve_path('/i440fx')
set_object_property(pci_bus_name, 'slot[2.0]', 'my-nic')

The device name is a unique identifier that can be used to select a
specific device.  The path is a relative way of selecting devices
given a chain of properties - you only use property names in a path,
not device names.  Is this correct?

For convenience I imagine people would prefer this:
create_object('rtl8139', 'my-nic')
set_object_property('/i440fx', 'slot[2.0]', 'my-nic')

So here set_object_property() detects that there is a '/' in the
device name.  Therefore it treats the argument as a path instead of a
device name.  We'd need to add the constraints that paths always start
with '/' and device names may not contain '/'.

Anyway, did I understand the independence of paths and device names correctly?

Stefan



reply via email to

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