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

[Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

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