[PATCH] Open Firmware device tree virtual filesystem

[Segher Boessenkool]

>> I'd like to put in my $.02 in favor of having a way to pass the OF
>> device tree to the kernel, in much the same way we pass stuff like
>> ACPI and PIRQ and MP tables now.
>
> This works fine for just passing the device tree, but it will fail for
> the next step of being able to use the firmware in the OS, and 
> returning
> sanely to the firmware.

Not everyone wants/needs that.  Flexibility is key.

>> - any path that uses kexec (since the first kernel probably shut down
>>   OF)
>
> No, that path works fine. The first kernel uses OFW, so it wont shut it
> down. Only thing is you need to pass the callback to the loaded kernel.

Depends.  The kernel _can_ shut down OF; in that case, it
becomes responsible for passing the device tree along to
the kexec'd kernel.

>> - etherboot
>
> ok, well.

Heh :-)

>> OFW is open source now. I think it's time to reexamine the basic
>> assumptions about the need for a callback, and see if something better
>> can't be done.
>
> I fully agree. And I believe there are very good things that can be 
> done
> with callbacks. The reasons callbacks are evil is that you dont know
> what you call into. This is not at all the case here. It's a mere
> function call that calls some highly board specific code, not unlike 
> all
> the calls we do in LinuxBIOS already today. Since we're 100% open
> source, we don't "cross a border" anymore.

Oh you *do* cross a border, and that is a good thing here; it
is a stable API, and that makes a lot of sense here.

> - 16bit legacy callbacks
> - (u)efi legacy callbacks
> - existing openfirmware support code for non-x86 platforms.
>
> But: It is a first step that, as a mid-term goal, allows us to unify 
> OFW
> support on all platforms to some extent.

Yes.

>> Mitch, is there some way to get OF device tree to the kernel without
>> involving a callback? That would be quite nice.
>
> That is a nice idea, but unless there is any LinuxBIOS version that
> creates such a device tree and exports it as a data structure to the 
> OS,
> why would we want to add such support to the Linux kernel?

The PowerPC arch code already handles this.


Segher