linux-kernel - Re: [RFC] [PATCH] Device Tree on ARM platform

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]

Date:	Fri, 29 May 2009 13:52:16 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Mitch Bradley <wmb@...mworks.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	devicetree-discuss@...abs.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Fri, 2009-05-29 at 09:59 +0800, Mitch Bradley wrote:
> I have an embeddable FCode interpreter that could be built into a 
> kernel.  Perhaps it's time to resurrect that.  The total size is on the 
> order of 50K with debugging tools included; probably more like 35K if 
> stripped down to just the essentials.

It's interesting... might be an option. I tend to prefer myself having
the methods be properly documented by the HW designer, and implemented
as C code in the kernel, for various reasons.

There are pro and cons to both approaches. We could define special
properties to embed f-code in the device-tree and run it that way, it's
probably a more business-friendly method :-) IE. It makes it possible
to completely avoid board specific code in the kernel, possibly making
it feasible to run existing distributions on new HW to a certain
extend by just updating those scripts.

But it comes with some drawbacks too... too often, this stuff will
replace good documentation, the scripts provided by the FW will be
busted in subtle ways that the kernel will have to work around, and thus
it can be used as a way to avoid documenting or open sourcing things and
obfuscating operations.

So at this stage, my personal preference goes for well defined methods
named by the device tree and implemented by the kernel natively. But
people are free to disagree with me on this one.

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