Hi Everyone, We are again considering running the devicetree.cb files through the C preprocessor before they're used by sconfig to generate the static configuration structures. This suggestion came up due to the desire to be able to have some control of devicetree with Kconfig. See footnote [1].
We discussed this previously in 2022-06-29 leadership meeting and decided not to use the C preprocessor at that point. Unfortunately the discussion and reasons for this decision were not captured in the minutes.
Proposed rules: The standard coreboot header files can be included and used, similar to how we do things with the .asl files now. We'll have a way to exclude sections of the header file that aren't appropriate to be included.
Allowed: - #include, of course - #if, #ifdef, #else, #elif, #endif and the like may be used. - #define is allowed only for simple Object-like macros
Forbidden: - Function-like macros or any macros that take arguments may not be used, even if included from header files. The single exception is the CONFIG() macro to unify with the rest of coreboot. - Standard pre-defined macros like __FILE__ and __TIME__ should not be used - #undefine, #ident, #sccs, #line, and #pragma should not be used in devicetree files. - Obsolete features such as #assert and #unassert should not be used - Using build time macros defined in the Makefile (compiling with a -D option)
These rules are proposed to limit the impact of the C preprocessor, and to try to prevent everything from just becoming a series of function-like macros. This could dramatically modify how the devicetrees are created, which is not what we're looking for.
Question: If we do use the C preprocessor, do we want to get rid of '#' as the character to begin comments and switch to '/* */' & '//' C-style comments? The reasoning behind this is that the # comment style could get confused with the preprocessor commands. If # is a comment in devicetree, and someone types #efine instead of #define, there won't be an error, and could make debugging the issue more difficult than it needs to be.
Martin
Note: Even though proposal could greatly extend the flexibility of the devicetree, I'm not really a proponent of this idea. I'd rather add to the devicetree.cb grammar and generate the static code that uses the config options as discussed in [1]. If using the C preprocessor is the general preference though, I'll get behind that.