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: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Thu, 15 Sep 2011 08:17:13 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 09/15/2011 01:31 AM, Gleb Natapov 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?

get_fw_dev_path() won't exist in QOM. The fact that it exists in qdev is a problem with qdev.

This function generates Open Firmware device path.

The function generates *a* OF device path. OF is not a canonical representation of arbitrary hardware. It's a representation chosen (usually by a human) of what information about the hardware is needed by the OS-level software.

If you look at what other folks have done with OF integration in QEMU, you'll see a recurring theme of two OF trees, one used to create the hardware and the other that is actually exposed to the guest. The reason you need two is because guests sometimes expect very specific things that you really can't generate programmatically in every circumstance.

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?

All of the information needed to generate an OF tree is available as device properties. To the extent that you need to knowledge of each bus to generate a OF path component, you'll need some extra knowledge of each bus to do that (just like with qdev today). But that knowledge will definitely not be part of QOM.

Paths are not part of QOM. They're representations used by client software to navigate the QOM graph. There is no real need to make paths part of QOM explicitly.

Regards,

Anthony Liguori



reply via email to

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