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: > > 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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev