[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Machine description as data
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [RFC] Machine description as data |
Date: |
Thu, 12 Feb 2009 14:50:49 +1100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Wed, Feb 11, 2009 at 12:57:19PM -0600, Hollis Blanchard wrote:
> 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.
Note that despite "interrupt tree" being the normal terminology, it's
actually a DAG, which is Hollis' point.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
- [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/11
- Re: [Qemu-devel] [RFC] Machine description as data, Ian Jackson, 2009/02/11
- Re: [Qemu-devel] [RFC] Machine description as data, Hollis Blanchard, 2009/02/11
- Re: [Qemu-devel] [RFC] Machine description as data, Blue Swirl, 2009/02/11
- Re: [Qemu-devel] [RFC] Machine description as data, David Gibson, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Carl-Daniel Hailfinger, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, M. Warner Losh, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Carl-Daniel Hailfinger, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/13
- Re: [Qemu-devel] [RFC] Machine description as data, David Gibson, 2009/02/12