(dropped Hung-Te off the list somehow...)
On Wed, Mar 6, 2019 at 12:49 PM Julius Werner jwerner@chromium.org wrote:
Sounds like a good plan. Please keep Documentation in sync: Documentation/core/Kconfig.md seems to cover the implementation details.
Uhh... where did you find that one? I don't see it in my tree anywhere...
Will it be more explicit if we call it HAS_CONFIG(XXX) ? Or HAS_KCONFIG(XXX) CONFIG(XXX) seems too generic to me that some drivers may wan to use it for wrapping a reference to config tables, like GPIO(XXX).
Hmm... I would really like to keep it as short as possible, and that's another 4 chars. Also, I feel HAS_CONFIG may be a bit confusing (e.g. may sound more like whether the config is used at all in a particular board/SoC/arch, rather than whether it is enabled). I guess we could go with KCONFIG(XXX) if you prefer, but I kinda liked the symmetry between CONFIG_XXX and CONFIG(XXX).
I would say that the rules for the global namespace are first come, first pick. There are currently no macros named CONFIG() in the tree, and after this is introduced, nobody can add another one (since kconfig.h is force-included in every file and would lead to a duplicate definition). Of course normally we want to avoid names that are too generic in the global namespace, but for something as ubiquitous and useful as this I think we can make an exception (because I doubt any other use case could have a better justification for claiming this name).