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

[Gleb Natapov <gleb@redhat.com>]

On Thu, Sep 15, 2011 at 08:17:13AM -0500, Anthony Liguori wrote:
> 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.
> 
I do not need get_fw_dev_path() as such. I need the way to generate OF
device path for a device. I hope you are not saying that the fact that
we generate OF path is the problem of qdev. OF device path is an ABI
between QEMU and a firmware. Firmware can't do much with QOM device
paths.

> >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.
> 
Of course it is chosen by human, just like QOM is the representation
chosen by human :) But human made sure that it presents enough information
for OS level software to unambiguously determine a device a path points
too.

> 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.
> 
With qdev buses are different from devices so it is very clear where to
put that extra knowledge (inside get_fw_dev_path callback of a bus). How
are you going to do that with QOM? As you said in your other email QOM
is a graph, so dumb recursion will not work like it did in qdev. At each
node you need to know which link to take.

> 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.
> 
I am not saying there is. I just what to make sure that we will not
regress by moving to QOM.

--
			Gleb.