linux-kernel - Re: [PATCH] Open Firmware device tree virtual filesystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Jan 2007 10:39:47 -0700
From:	"ron minnich" <rminnich@...il.com>
To:	"OLPC Developer's List" <devel@...top.org>,
	"Linux Kernel ML" <linux-kernel@...r.kernel.org>,
	"Mitch Bradley" <wmb@...mworks.com>
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem

Mitch Bradley wrote:
> Request for comments.

Sorry to revive this thread, I just ran through the discussion. I'm
about 50% in agreement with the idea.

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.

I'd like to also put in my $.02 in OPPOSITION go doing this via
callofw() or any bios callback mechanism.

We have hoped, for some years now, to use the OF device tree as a way
to pass information from (e.g.) LinuxBIOS to the kernel. It seemed
like a solid and tested path. The various kernels understand the tree,
especially non-linux kernels which LinuxBIOS boots. It's a simple
format and well-designed, unlike ACPI. We have always though it was a
very nice design.

But any mechanism that depends on a callback to OFW is way too
limiting. As soon as you put that callback in, you lock out
- uBoot
- LinuxBIOS
- Bochs BIOS as used in Xen and other hypervisors and emulators
- any path that uses kexec (since the first kernel probably shut down
   OF)
- etherboot
- GNUFI

So, while the idea of the OF tree is very general, and IMHO very
desirable, the idea of the callback is very specific to one firmware
implementation on one CPU architecture on one platform -- the OLPC --
and is hence not desirable at all.

An idea that is potentially applicable and usable on all BIOSes
becomes usable on only one.

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. Also, as others mentioned, callback into any sort of
firmware on SMP can and does get messy. I've seen this in practice on
EFI-based machines.

Otherwise, this is just too limited to be of any use to those of us
doing more than just OFW.

Mitch, is there some way to get OF device tree to the kernel without
involving a callback? That would be quite nice.

thanks

ron
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/