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: Fri, 16 Sep 2011 14:29:51 -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/16/2011 02:13 PM, Gleb Natapov wrote:
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.

Graphs don't have roots.

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.

No, it's very easy. Something just has to decide where to start the transversal, and then walk the graph starting at that node until they find the node. They need to map each node to whatever the OF representation is that makes sense.

A tree is just a degenerate graph so going from QOM to OF is easy. It just requires looking at a subset.

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.

To be fair, it's not an ABI that is supported. We only need to support a single BIOS version that we provide.

But that's just splitting hairs.  You can still generate these paths.

Regards,

Anthony Liguori



reply via email to

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