From: Segher Boessenkool <segher@kernel.crashing.org>
To: Stefan Reinauer <stepan@coresystems.de>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
ron minnich <rminnich@gmail.com>,
"OLPC Developer's List" <devel@laptop.org>,
Mitch Bradley <wmb@firmworks.com>
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem
Date: Thu, 11 Jan 2007 19:47:10 +0100 [thread overview]
Message-ID: <e31af5463dc2a8d051b632f54e65decf@kernel.crashing.org> (raw)
In-Reply-To: <20070111182041.GA6243@coresystems.de>
>> 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
next prev parent reply other threads:[~2007-01-11 18:46 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-11 17:39 [PATCH] Open Firmware device tree virtual filesystem ron minnich
2007-01-11 17:53 ` Mitch Bradley
2007-01-11 17:55 ` ron minnich
2007-01-11 18:36 ` Segher Boessenkool
2007-01-11 18:20 ` Stefan Reinauer
2007-01-11 18:47 ` Segher Boessenkool [this message]
2007-01-11 19:12 ` ron minnich
2007-01-11 19:11 ` ron minnich
-- strict thread matches above, loose matches on Subject: below --
2006-12-31 1:38 Mitch Bradley
2006-12-31 5:19 ` David Miller
2006-12-31 9:36 ` Mitch Bradley
2006-12-31 9:52 ` David Miller
2006-12-31 10:11 ` David Kahn
2006-12-31 10:49 ` David Miller
2006-12-31 11:47 ` Rene Rebe
2006-12-31 11:53 ` David Kahn
2007-01-01 3:48 ` Segher Boessenkool
2007-01-02 3:56 ` Benjamin Herrenschmidt
2007-01-02 18:43 ` Richard Smith
2006-12-31 15:41 ` Christoph Hellwig
2006-12-31 20:46 ` David Miller
2007-01-01 3:37 ` David Kahn
2007-01-01 8:54 ` David Miller
2007-01-02 4:02 ` Benjamin Herrenschmidt
2007-01-02 12:28 ` Segher Boessenkool
2007-01-01 3:33 ` Segher Boessenkool
2007-01-01 8:57 ` David Miller
2007-01-01 17:48 ` Segher Boessenkool
2007-01-01 23:08 ` David Miller
2007-01-01 23:52 ` Segher Boessenkool
2007-01-02 3:31 ` David Miller
2007-01-02 11:26 ` Segher Boessenkool
2007-01-02 1:40 ` David Kahn
2007-01-02 3:36 ` David Miller
2007-01-01 18:10 ` Mitch Bradley
2007-01-01 19:21 ` Jan Engelhardt
2007-01-02 4:05 ` Benjamin Herrenschmidt
2007-01-02 4:30 ` David Miller
2007-01-02 4:57 ` Benjamin Herrenschmidt
2007-01-02 5:01 ` David Miller
2007-01-02 5:09 ` Benjamin Herrenschmidt
2007-01-02 5:44 ` David Miller
2007-01-02 12:36 ` Segher Boessenkool
2007-01-02 11:03 ` Segher Boessenkool
2007-01-02 3:53 ` Benjamin Herrenschmidt
2007-01-02 12:22 ` Segher Boessenkool
2007-01-02 20:12 ` Benjamin Herrenschmidt
2007-01-02 21:28 ` Segher Boessenkool
2007-01-02 21:32 ` Benjamin Herrenschmidt
2007-01-02 21:40 ` Segher Boessenkool
2007-01-02 22:10 ` David Miller
2007-01-02 22:05 ` David Miller
2007-01-03 0:48 ` Segher Boessenkool
2007-01-03 4:34 ` David Miller
2007-01-03 15:23 ` Segher Boessenkool
2007-01-04 2:15 ` David Miller
2007-01-02 3:45 ` Benjamin Herrenschmidt
2007-01-02 3:49 ` David Miller
2007-01-02 11:45 ` Segher Boessenkool
2007-01-02 20:07 ` Benjamin Herrenschmidt
2006-12-31 13:24 ` Pekka Enberg
2006-12-31 18:55 ` Mitch Bradley
2006-12-31 14:12 ` Jan Engelhardt
2006-12-31 20:45 ` David Miller
2006-12-31 21:30 ` Jan Engelhardt
2007-01-02 3:43 ` Benjamin Herrenschmidt
2007-01-02 11:37 ` Segher Boessenkool
2007-01-02 13:22 ` Stefan Reinauer
2007-01-02 20:08 ` Benjamin Herrenschmidt
2007-01-02 20:11 ` Mitch Bradley
2007-01-02 20:48 ` Benjamin Herrenschmidt
2007-01-02 21:37 ` Segher Boessenkool
2007-01-02 21:47 ` Benjamin Herrenschmidt
2007-01-03 0:35 ` Segher Boessenkool
2007-01-03 0:44 ` Benjamin Herrenschmidt
2007-01-03 1:14 ` Segher Boessenkool
2007-01-03 4:35 ` David Miller
2007-01-02 22:07 ` David Miller
2007-01-03 0:52 ` Segher Boessenkool
2007-01-03 1:13 ` Jan Engelhardt
2007-01-03 4:38 ` David Miller
2007-01-03 5:05 ` Benjamin Herrenschmidt
2007-01-03 15:59 ` Segher Boessenkool
2007-01-03 15:31 ` Segher Boessenkool
2007-01-03 4:34 ` David Miller
2007-01-02 21:15 ` Segher Boessenkool
2007-01-02 21:59 ` David Miller
2007-01-01 3:40 ` Segher Boessenkool
2007-01-01 4:21 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e31af5463dc2a8d051b632f54e65decf@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=devel@laptop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rminnich@gmail.com \
--cc=stepan@coresystems.de \
--cc=wmb@firmworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.