On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote:

quoted

We use that to suck the device-tree, which we flatten, and then

re-enter

quoted

the kernel with the "common" entry interface.

I don't think I want to do the same on ARM.  I'd rather have the
prom_init stuff in a boot wrapper, or have OFW itself generate the
flat representation before booting the kernel.

But then it's no longer OF. IE. A compliant OF implementation provides a
client interface API :-)

This is going to be especially important if Mitch wants to keep OF
alive.

I suppose it could be done via a wrapper like prom_init, which flattens
the tree, and sticks somewhere in a property the address of the OF
client interface callback though it's a tad awkward. If well defined, I
suppose Mitch might even be able to make his OF natively boot kernels
that way but that's of course up to him.

I'm trying to constrain the number of things that could go wrong by
defining only one way for getting the device tree data into the
kernel.

I understand, and the flattened method is the most versatile, I'm just
pointing out the situation here :-)

Right.  We don't need to use OFW/RTAS to handle this use case.

Definitely not. It will depend on whatever hypervisor interface is
implemented in a given environment. Though I do like the idea of passing
precompiled bits of .dtb around for hotplug :-) We could make that a
standard way of KVM to do things in embedded space.

Cheers,
Ben.