[Top][All Lists]

[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: Fri, 16 Sep 2011 21:12:19 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 09/16/2011 08:11 PM, Edgar E. Iglesias wrote:
On Fri, Sep 16, 2011 at 11:10:19AM -0500, Anthony Liguori wrote:
On 09/16/2011 09:46 AM, John Williams wrote:
On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori<address@hidden>   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:


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

That need not be the case - with the


syntax, device trees can be topologically accurate descriptions - this
is part of our still-unreviewed patchset,

It's not unreviewed.  Any type of machine configuration needs to be
done using qdev/qom factory interfaces, not implementing custom
logic tied to a config format.

Can you construct OF paths based on link attributes?  What would
that look like in practice?

Another counter-example - our device trees are autogenerated out of a
high level system synthesis tool.  One path is a device tree for QEMU
and kernel configuration, the other is to actually create the system
based on a high level design specification.

That's all well and good, but the mechanism that I think is
important to have in QEMU is a programmatic interface for
constructing and manipulating the guest devices.  A config file is
not a programmatic interface.  You can implement config file support
in terms of a programmatic interface but implementing the later in
terms of the former is extremely painful.

I agree, but I also thinik that we have to be a bit pragmatic

It's not pragmatic to leave something that's mostly broken alone and tack on something new that replicates the function to gain a new feature.

It just results in more cruft and makes it harder to ever fix the real problem.

in the
sense that if the external interfaces won't be available until years
from now, we should take iternmediate steps.

These are the intermediate steps:


We really aren't that far away from fixing qdev and making all of these problems go away.

We've all got imaginary interfaces in our minds, but as long as
these are nowhere near reality,

They are very much reality and they aren't imaginary. Code exists, we just need to move in a common direction here and spend some time fixing past mistakes.


Anthony Liguori

reply via email to

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