Dear Stephen,
In message 51A6869F.1020004@wwwdotorg.org you wrote:
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;
I am not 100% sure of that. First, it's not correct to say "compiled compile the same way everywhere" - it's not that "where" it compiled, butthe "for which machine", i. e. which exact cross tool chain is selected.
And I can well imagine DTs that include parts for specific IP blocks, where the exact details might depend on the target architecture. We see an incresing number of cases where the same IP blocks are being used in different architectures, even of different endianess, etc. So even if this appears not useful or needed today, I think we should not intentionally barr the way unless that would realy cause problems to us.
Or do you see a real potentiol of conflict with the classed "reserved namespaces" in GCC with double underscores?
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.ht...
One of which was:
- No gcc built-in define usage
I understand that was part of some discussion then. But has it been generally agreed on, and eventually even turned into a DT policy document?
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 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.
"-x assembler-with-cpp" makes sense for other reasons, i. e. being able to mark related lines incommonly used header files with __ASSEMBLER__ and making sure that '#' gets only processed when in column 1. It does NOT solve the indetifier problem, though, as GCC will still define "unix" and :linux" (and eventually more):
-> gcc -E -dM -x assembler-with-cpp - < /dev/null | grep -v _ #define unix 1 #define linux 1
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.
Why do you want to stop something which doesn't hurt you, but might eventually be useful in other cases?
No, I do not have any real such use cases at hand, but I can see that it might be for example useful to auto-detect the certain properties of the system we're building for.
Oh, and another of Rob's proposed rules:
Agreed, another propsal...
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
OT here, but: Don't you see a risk that such arch specific things might become a problem soon?
Best regards,
Wolfgang Denk