[U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Stephen Warren]

On 05/29/2013 03:33 PM, Wolfgang Denk wrote:
> Dear Stephen,
> 
> In message <51A634B5.5060309 at wwwdotorg.org> you wrote:
>>
>>> I think this is not a good way to address this issue.  The GCC
>>> documentation (section "System-specific Predefined Macros" [1])
>>> desribes how this should be handled.  The "correct" (TM) way to fix
>>> this is by adding "-ansi" or any "-std" option that requests strict
>>> conformance to the compiler/preprocessor command line.
>>>
>>> [1] http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros
>>
>> -ansi at least was considered when the Linux kernel patches for dtc+cpp
>> support were being developed, but it was rejected. While it possibly
> 
> Can you provide references?  I'd like to understand why it was
> rejected - it seems to be the "official" approach to the problem.
> 
>> does solve this specific issue fine, there were other more general
>> problems; IIRC (and I might not) it completely changes the way macro
>> expansion happens, which results in it being pretty useless. Hence, "-x
>> assembler-with-cpp" was chosen over e.g. "-ansi".
> 
> Again, do you have any reference?  "completely changes the way macro
> expansion happens" sounds terribly dangerous, so it would be better to
> know about that exactly...

Sorry, I was thinking about -traditional-cpp, not -ansi. We had
considered -traditional-cpp as a workaround because DT uses property
names that start with #, and this triggered cpp to treat them as macro
names, which went wrong. However, due to -traditional-cpp being quite
different from ISO cpp, we selected -x assembler-with-cpp instead, which
both implements an ISO cpp, but also only handles pre-processing
directives with the # in column 1.

Now, let's discuss -ansi vs. -undef some more.

Since DT is supposed to be a HW description, it shouldn't be using cpp's
built-in macros to compile in different ways; there really isn't a
concept of the "target arch of compilation"; a .dts file should simply
compile the same way everywhere. Different DTs represent different HW;
we don't use a single DT with conditional compilation to represent
different HW. This led Rob Herring (one of the kernel device tree
maintainers) to propose the following rules for cpp usage on device trees:

https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-October/020831.html

One of which was:

- No gcc built-in define usage

I don't see any disagreement with that bullet point in the thread, and
indeed it makes sense to me for the reasons I outlined above.

Some history on why we needed to not-define, or un-define, some macros
(such as the linux macro we're discussing here) can be found in:

http://linux-kernel.2935.n7.nabble.com/PATCH-V7-kbuild-create-a-rule-to-run-the-pre-processor-on-dts-files-td575632.html

The last few messages there end up mentioning -undef, which we/I ended
up using. It looks like -ansi wasn't mentioned at all when discussing
this issue.

However, I assert that -undef is better, since we end up without any
pre-defined macros, which DT files shouldn't be using anyway. By my
reading of the cpp manual link you send, -ansi simply stops
non-conforming pre-defined macros from being defined, but doesn't stop
them all being defined as -undef does. Hence, I prefer -undef.

Oh, and another of Rob's proposed rules:

- No kernel kconfig option usage

Would also imply that U-Boots config headers shouldn't be accessible
when compiling device trees. The last few kernel patches I sent to
enable dtc+cpp usage were specifically aimed at limiting the set of
headers that DT files can use to those specifically part of the DT
bindings, and not general Linux headers, For example, see the following
Linux kernel commit:

==========
kbuild: create an "include chroot" for DT bindings

The recent dtc+cpp support allows header files and C pre-processor
defines/macros to be used when compiling device tree files. These
headers will typically define various constants that are part of the
device tree bindings.

The original patch which set up the dtc+cpp include path only considered
using those headers from device tree files. However, most are also
useful for kernel code which needs to interpret the device tree.

In both the DT files and the kernel, I'd like to include the DT-related
headers in the same way, for example, <dt-bindings/gpio/tegra-gpio.h>.
That will simplify any text which discusses the DT header locations.

Creating a <dt-bindings/> for kernel source to use is as simple as
placing files into include/dt-bindings/.

However, when compiling DT files, the include path should be restricted
so that only the dt-bindings path is available; arbitrary kernel headers
shouldn't be exposed. For this reason, create a specific include
directory for use by dtc+cpp, and symlink dt-bindings from there to the
actual location of include/dt-bindings/. For want of a better location,
place this "include chroot" into the existing dts/ directory.

arch/*/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings

Some headers used by device tree files may not be useful to the kernel;
they may be used simply to aid in constructing the DT file (e.g. macros
to create a node), but not define any information that the kernel needs
to share. These may be placed directly into arch/*/boot/dts/ along with
the DT files themselves.
==========