On Aug 8, 2006, at 6:42 PM, Hollis Blanchard wrote:
I remember seeing some mention of it, but I don't think we currently
have an IEEE1275 binding describing the contents of the /xen node.
[...]
start-info is going away, which means we'll need to add more
properties
to replace it... something like this:
xen {
name = "xen";
version = "Xen-3.0-unstable";
Should we have a "compatible" that domain can compare against?
reg = <0 @DOMAIN_ID@ 0 0>;
This could certainly be "domain-id" and be one cell.
I used "reg" because I mistakenly thought is was a mandatory property
and we needed a "unit-id" which makes no sense as you point out below.
It is 2x2 cells because:
/#address-cells: 2
/#size-cells: 2
and they dictate the size of the unit-address.
domain-name = "@DOMAIN_NAME@";
shared = <@SHARED_INFO@>;
This, console and store, and all addresses should be expressed in
bytes and are domain-physical not MFNs so we should label them
correctly. They also need to match /#address-cells and should prolly
have a size.
privileged;
init-domain;
console {
name = "console";
interrupts = <@CONSOLE_EVTCHN@ 0>;
FYI, the second zero here denotes a sense code of 0 indicating
positive edge triggered interrupt
frameno = <@CONSOLE_MFN@>;
Perhaps this should be a "unit address" and be a reg property, that
actually makes sense.
};
store {
name = "store";
interrupts = <@STORE_EVTCHN@ 0>;
frameno = <@STORE_MFN@>;
this could be a "reg"/"unit address" as well.
};
};
What are all the extra 0s in there? Why do we want a reg property when
we can use separate explicitly-named properties?
see above.
-JX
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
| 
Home