[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Machine description as data

From: Hollis Blanchard
Subject: Re: [Qemu-devel] [RFC] Machine description as data
Date: Wed, 11 Feb 2009 12:57:19 -0600

On Wed, 2009-02-11 at 16:31 +0000, Ian Jackson wrote:
> Markus Armbruster writes ("[Qemu-devel] [RFC] Machine description as data"):
> > [stuff]
> Yes, this is a good approach.  I have one question though:
> >    Define an internal machine configuration data structure.  Needs to be
> >    sufficiently generic to be able to support even oddball machine
> >    types.  Make it a decorated tree, i.e. a tree of named nodes with
> >    named properties.
> Many real systems are not strictly tree-structured, because there are
> hardware devices which connect via several different paths.  For
> example, much hardware supported by OpenWRT comes with a built-in
> bridge chip connected internally to a hidden ethernet card; a tape
> library would have one interface for the robot and a bunch of SCSI
> tapereaders; etc.

I'm not sure these are great examples, since there still a clear
hierarchy here (e.g. the ethernet card is "behind" the bridge chip).
Also, there is already established practice for representing SoC devices
(found in many embedded PowerPC processors): see arch/powerpc/boot/dts.

However, what *is* a good example would be the interrupt hierarchy,
which can be totally separate from the address/data hierarchy.

The device tree is about *devices*, not interfaces. Each node (device)
can mark itself as implementing multiple interfaces, which is what the
"compatible" property is about.

> When an emulation of such a device starts up, it will want to bind to
> several parents.  How will you represent this ?

There is established design for representing the interrupt hierarchy in
IEEE1275, using explicit "interrupt-parent" properties to create the
interrupt tree.

Hollis Blanchard
IBM Linux Technology Center

reply via email to

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