Re: Request review of device tree documentation

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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

> Either fought or embraced.  To the extent that it is possible to focus 
> solely on Linux and ARM, one could image doing a good HAL.

That will come with a huge amount of comunity resistance sadly, but I
can imagine distros liking it.

In general, I much prefer having all the necessary native drivers in the
kernel, and the device-tree to provide the right representation, and
avoid trying to abstract "methods" via a HAL. It's the Linux philosophy
as much as possible (even when defeated by ACPI).

But if we're going to be forced by vendors into HALs, we can also make
sure that whatever they come up with is half reasonable :-)
 
> (The reason I say ARM-only is  because the
> only other non-x86 architecture that has any "legs" left is PowerPC, and 
> PPC already has a coherent story.)

Well, ppc story isn't that coherent as far as this goes :-) We don't
keep OF alive, we have RTAS which is a pile of poo... etc...

But yeah, we are fine without a HAL, so if we stick to OF as a
bootloader and provider of the device-tree, we are fine.

> > To some extent, in fact, doing that sort of stuff in OF or even in RTAS
> > like we do on power is even worse than ACPI-like tables. At least with
> > those tables, the interpreter is in the operating system, thus can run
> > with interrupts on, scheduling on, etc...
> 
> I have an FCode interpreter that can live inside the OS.  It's 
> considerably simpler than the ACPI interpreter.

That's the one thing I purposefully avoided mentioning :-)

It's an interesting idea, I've though about it. If course, there's all
sort of things to be careful about, such as who provides the f-code with
virtual->physical mappings to devices, how they are represented, how
much of the OF "forth" environment is accessible to such f-code, locking
between f-code and kernel use of shared resources (especially true when
dealing with things like i2c devices, plls, etc...).

IE. THe base idea is simple. The implementation can be a huge can of
worms.

Cheers,
Ben.

> >  With RTAS, or client interface
> > calls, you'll end up with potentially huge slumps of CPU time "lost"
> > into the bowels of the firmware.
> >
> >
> > Cheers,
> > Ben.
> >
> >
> >