Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 12:45:40PM -0600, Stephen Warren wrote:
> On 10/10/2012 12:23 PM, Mitch Bradley wrote:
> > On 10/10/2012 7:09 AM, Rob Herring wrote:
> >> On 10/09/2012 04:16 PM, Stephen Warren wrote:
> >>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
> >>>>>
> >>>>> What more do you think needs discussion re: dtc+cpp?
> >>>>
> >>>> How not to abuse the ever-loving shit out of it? :-)
> >>>
> >>> Perhaps we can just handle this through the regular patch review
> >>> process; I think it may be difficult to define and agree upon exactly
> >>> what "abuse" means ahead of time, but it's probably going to be easy
> >>> enough to recognize it when one sees it?
> >>
> >> Rather than repeating things over and over in reviews, we should
> >> document at least rules we can easily agree on and then add to it when
> >> people get "creative." Also, I can't keep up with every single binding
> >> review as is, and this could just add another level of complexity to the
> >> review. A few off the top of my head and from the thread discussion:
> >>
> >> - Headers must be self contained with no outside (i.e. libc, kernel,
> >> etc.) header dependencies.
> >> - No kernel kconfig option usage
> >> - No gcc built-in define usage
> >> - No unused items (i.e. externs, structs, etc.)
> >> - No macro concatenation
> >> - No macros for strings or property names
> > 
> > Instead of making a bunch of rules about how you can only use a small
> > subset of cpp, why not just add a "define name value" command to DTC?
> 
> I implemented a patch to do exactly that, and it was rejected because it

Well... more indefinitely postponed, rather than rejected.  Which you
would be entirely justified in seeing as a meaningless semantic
difference at this point.

> only solved part of the problem (named constants) and not the reset (a
> completely generic macro language/... within dtc). The argument was that
> defining just the named constant syntax on its own without knowing what
> the unspecified future macro language will look like might result in the
> named constant syntax not fitting into it.
> 
> That all said, I now think that using cpp is actually a much better
> solution that adding yet more dtc-specific syntax. The *huge* benefit
> here is that it allows you to share .h files between *.dts and C code,
> so you don't have to write out the same set of #defines once in dtc
> syntax and once in cpp syntax.

Right, I tend to agree.  In addition to those reasons, it avoids
creating yet another micro-language, and it obeys the #1 guiding
principle for dts syntax which is "don't surprise C programmers".

That said, there are a number of number of dtc extensions that would
make cpp-ability more useful.  The integer expression support that has
already gone in was a start on that, but richer expressions
(particularly strings and bytestrings) would be useful too.  Support
for invoking cpp automatically from within dtc would make that support
easier to use too.

I really would like to be working more actively on those things, but
unfortunately I don't have that much time free for dtc work.

-- 
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/