lkml.org 
[lkml]   [2012]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>


\
 
 \ /
  Last update: 2012-10-10 21:41    [W:0.660 / U:1.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site