On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
[off-list ref] wrote:

On Sat, 2010-06-12 at 06:30 -1000, Mitch Bradley wrote:

quoted

I'm certainly going to try keeping OFW alive. =A0On the x86 OLPC machine=

s,

quoted

the ability to
dive into OFW via a SysRq key combo was very helpful for debugging some
difficult
problems. =A0The team has asked me to support the feature on ARM.

Oh well, if you can and can convince the ARM kernel folks to do the
necessary changes ... :-)

What is needed to keep OFW alive?  I've got no problem with doing so
if it isn't invasive, and as long as the same boot entry interface can
be used.

One thing tho, you will only benefit from the whole infrastructure we
have created accross platforms in linux if the device-tree is "sucked"
into linux at boot. IE. Linux will not do constant accesses to OF for
the DT. Even sparc converted to that now.

That means that if your device-tree has a dynamic nature, we'll need to
come up with a way to inform the kernel of changes in it so it can
update it's copy accordingly.

What is the use-case for having a dynamic device tree?  I can see
keeping OFW alive being useful for some debug facilities, but once the
kernel has started, I'm really not interested in relying on firmware
to manage the hardware.  (but then again it's no secret that I'm
suspicious of anything that depends on runtime interaction with
firmware).

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.