[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: Gleb Natapov
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Fri, 16 Sep 2011 22:13:52 +0300

On Fri, Sep 16, 2011 at 01:42:02PM -0500, Anthony Liguori wrote:
> On 09/16/2011 01:22 PM, Gleb Natapov wrote:
> >Then we are arguing about minor detail. But according to you this minor
> >detail will prevent us from walking device tree up to the root, so it is
> >not so minor for me.
> There is no root.  It's not a tree.  The composition tree (which
There is "virtual root". System bus in qdev speak. You can create one
explicitly like qdev did or you can say that if a device has no parent
it is on a system bus.

> we've been talking about using for canonical pathnames) has nothing
> to do with the buses.

I do not care about canonical pathnames you are talking about too
much. The reason is that they are useless outside of QEMU. The problem
we need to solve is to name a device in such a way that it can be found
without knowing any QEMU implementation details. This is not for internal
QEMU use (for that you can use canonical pathnames you are talking about),
but for communicating device location outside of QEMU. Currently we pass
OF device paths to firmware and this is ABI QEMU expose to a guest, so
QOM needs to preserve it. What I asked is how it can be done with QOM and
you are saying that it can't be done and this is not a very good answer.
ABI requires OF path to be built not for all QEMU devices, but only for
those that support bootindex property, so this may make our task more
simple, although I think the correct solution should be generic. So
lets think about solutions to the very real problem instead of arguing.

> Moreover, the composition tree doesn't have a single root.  It's got
> multiple root nodes (any user created device is a root node of a
> composition tree).
We are interested in a device tree (or graph) as see from a CPU node.


reply via email to

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