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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1167709406.6165.6.camel@localhost.localdomain>
Date:	Tue, 02 Jan 2007 14:43:26 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	David Miller <davem@...emloft.net>
Cc:	jengelh@...ux01.gwdg.de, wmb@...mworks.com, devel@...top.org,
	linux-kernel@...r.kernel.org, jg@...top.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem


> I'm incredibly surprised how much resistence there is from the
> i386 OFW folks to do this right.  It would be like 80 lines of
> code to suck the device tree into kernel memory, or if they don't
> want to do that they can use inline function wrappers to provide
> the clean C-language interface to all of this and the cost to
> i386-OFW would be zero with the benefit that other platforms could
> use the code potentially.
>
> Doing the same thing 3 different ways, knowingly, is just very bad
> engineering.  That is how you end up with a big fat pile of
> unmaintainable poo instead of a clean maintainable source tree.  If we
> fix a bug in one of these things, the other 2 are so different that if
> the bug is in the others we'll never know and it's not easy to check
> so people won't do it.
> 
> So please do this crap right.

I strongly agree. Nowadays, both powerpc and sparc use an in-memory copy
of the tree (wether you use the flattened format during the trampoline
from OF runtime to the kernel or not is a different matter, we created
that for the sake of kexec and embedded devices with no real OF, but the
end result is the same, a kernel based tree structure).

There is already powerpc's /proc/device-tree and sparc's openpromfs, I'm
all about converging that to a single implementation (a filesystem is
fine) that uses the in-memory tree.

Ben.



-
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/