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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 10 Oct 2012 08:52:40 -1000
From:	Mitch Bradley <wmb@...mworks.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Rob Herring <robherring2@...il.com>, Michal Marek <mmarek@...e.cz>,
	Stephen Warren <swarren@...dia.com>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: dtc: import latest upstream dtc

On 10/10/2012 8:40 AM, Stephen Warren wrote:
> On 10/10/2012 11: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
> 
> That seems to be potentially a very useful feature; I have no idea why
> we would ban that; it isn't banned in C code in the kernel is it?

It's used in the kernel.  It is useful, but it has an unexpected side
effect that can be extremely annoying - it can make it extremely
difficult to find a definition with grep.  All the grep hits will be for
the fully-expanded uses of a symbol, while the definition is "hidden" by
virtue of being synthesized by concatenation.

Maybe it's not a big deal in a small project, but in a code base the
size of the Linux kernel, where you don't know a priori where something
is defined, it can make you want to tear your hair out.

> 
>> - No macros for strings or property names
> 
> Property names I can understand. Property values - I can perhaps see a
> use-case for...
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@...ts.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 
--
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/