[PATCH] Open Firmware device tree virtual filesystem
segher at kernel.crashing.org
Thu Jan 11 13:47:10 EST 2007
>> 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
> sanely to the firmware.
Not everyone wants/needs that. Flexibility is key.
>> - any path that uses kexec (since the first kernel probably shut down
> 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.
>> 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
> 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
> 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
> support on all platforms to some extent.
>> 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
> why would we want to add such support to the Linux kernel?
The PowerPC arch code already handles this.
More information about the Devel