On Mon, 2010-06-14 at 10:25 +0100, Russell King - ARM Linux wrote:

On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote:

quoted

None of this is a deal-breaker for the kind of debugging tasks that are  
the primary use case for the callback.

Would you mind explaining what kind of tasks these callbacks will
be used for?

That's one of the thing I'm "touching" on in my previous reply...

(For those who didn't quite follow, the discussion here is about
allowing a real Open Firmware implementation on ARM with the feature of
leaving OF alive while the OS is up, which is something sparc does but
we never supported on ppc).

Ideally, if you keep open firmware alive, you can drop into it when the
kernel crashes for example, or in some other circumstances.

However, there's a lot of room for abuse here and I'm worried that if it
becomes widespread, we'll start seeing vendors use that as a way to do
some kind of HAL and hide various platform methods in there (clock
control, nvram, etc...).

Another option Mitch mentioned is to have the f-code interpreter (f-code
is OF tokenized forth format) in the kernel, but that doesn't completely
solve the problem of providing it with appropriate virtual mappings,
arbitrating access to HW resources, etc etc etc

OF as a FW/bootloader is great. OF alive along with the OS can be a nice
debugging tool under some circumstances but I am a bit more dubious as
to whether that's going to work out in practice. But I'd like to -not-
see it abused as some kind of HAL.

Cheers,
Ben.