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.
Hi Martin,
On 08.11.23 20:21, Martin Roth via coreboot wrote:
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]. [...] 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.
I very much agree. The preprocessor seems like a very big tool for the small problem discussed in [1]. The implementation would be simple, I guess. But with all the overhead of discussing rules, implementing linters, and trying not to make a mess where linters leave some slack, it seems much to complex for the original problem.
Personally, I wouldn't even want Kconfig option names in the device- trees. Due to the lack of scoping in Kconfig, the names are usually incredibly long. Additionally with the uppercase spelling, they would look alien in our devicetree. To control the on/off state of a device, I would suggest to match Kconfig names by convention. Since we already have names and naturally some scoping in the devicetree. For instance,
chip soc/amd/picasso device mmio 0xfedc4000 alias i2c_2 kconfig_enabled end end
Could become
.enabled = CONFIG(SOC_AMD_PICASSO_I2C_2_ENABLED),
Or if we want to allow defaults in case of absence of the Kconfig, it could be something like `kconfig(on)` or `kconfig(def_on)` or even with implied kconfig, just `default on` instead of `on`.
Nico
-
Martin Roth -
Nico Huber