linux-kernel - Re: dtc: import latest upstream dtc

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20121010231623.GG28467@truffula.fritz.box>
Date:	Thu, 11 Oct 2012 10:16:23 +1100
From:	David Gibson <david@...son.dropbear.id.au>
To:	Rob Herring <robherring2@...il.com>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Michal Marek <mmarek@...e.cz>,
	Stephen Warren <swarren@...dia.com>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	Scott Wood <scottwood@...escale.com>
Subject: Re: dtc: import latest upstream dtc

On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
> On 10/10/2012 10:16 AM, Stephen Warren wrote:
> > On 10/10/2012 01:24 AM, David Gibson wrote:
> >> On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
> >>> On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
[snip]
> > That's probably a reasonable idea, although I imagined that people would
> > actually split out the portions of any header file they wanted to use
> > with dtc, so that any headers included by *.dts would only include
> > #defines. Those headers could be used by both dtc and other .h files (or
> > .c files).
> 
> Used by what other files? kernel files? We ultimately want to split out
> dts files from the kernel, so whatever we add needs to be self
> contained. I don't see this as a huge issue though because the whole
> point of the DT data is to move that information out of the kernel. If
> it is needed in both places, then something is wrong.

People get very hung up on this idea of having the DT move device
information out of the kernel, but that was never really the
motivation behind it.  Or at least, not the only or foremost
motivation.

The DT provides a consistent, flexible way of describing device
information.  That allows the core runtime the kernel to operate the
same way, regardless of how the DT information was obtained.  The DT
could come from firmware, but it could also come from an intermediate
bootloader or from early kernel code.  All are perfectly acceptable
options depending on the constraints of the platform.

The idea of firmware supplying the DT is much touted, but while it's a
theoretically nice idea, I think it's frequently a bad idea for
practical reasons.  Those being, in essence that a) firmware usually
sucks, b) it's usually harder (or at least no easier) to replace
firmware with a fixed version than the kernel/bootwrapper and c)
firmware usually *really* sucks.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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/