Hi, Il giorno ven 16 ott 2026 alle ore 10:00 Quentin Schulz <[email protected]> ha scritto: > > Hi Massimo, > > On 10/14/26 8:22 PM, Massimo Pegorer wrote: > > Hi Quentin, > > > > Il giorno mer 14 ott 2026 alle ore 18:25 Quentin Schulz > > <[email protected]> ha scritto: > >> > >> Hi Massimo, > >> > >> On 10/2/26 6:36 PM, Massimo Pegorer wrote: > >>> The configuration options SPL_BSS_START_ADDR and SPL_BSS_MAX_SIZE are > >>> guarded by SPL_HAS_BSS_LINKER_SECTION and SPL_BSS_LIMIT options in the > >>> common/spl/Kconfig file where they are originally defined. Addition of > >>> a second config statement without 'depends on' guard causes these two > >>> options to be put in the configuration even when the guard is not > >>> selected, which is unneeded and sounds wrong. > >>> > >> > >> I'm sorry, I don't understand the issue. Can you clarify or provide a > >> way to reproduce the issue? Multiple definitions of the same Kconfig > >> symbol are "combined" as far as I know so this shouldn't be an issue. > > > > The reasoning is almost the same I've tried to explain in [1]. Sorry if it > > sounds like ancillary changes. But in this way qconfig tool is more > > effective > > and helpful. > > > > OK, so I *really* do not want to start doing this, especially if we > don't have anything to make sure we don't do the same "mistake" again in > the future. I'm sure there are *tons* of other symbols with a similar > issue. I was under the impression that Kconfig would simply merge > symbols of the same name, but this behavior seems to indicate there's > some additional gotchas (or bugs). It'd be nice to know if upstream > Linux suffers from the same issue or not. If not, then it's likely > because we are far behind Linux for the Kconfig we use. If it is, then > maybe it's a bug the Linux kernel isn't aware of and we/they should fix, > or the documentation isn't clear enough on how we can specify additional > information by "redefining" the symbol. > > There could be some issue depending on the parsing order for the > symbols, I think there's an importance for which symbol gets parsed > first before it is "redefined". > > Can you try to reproduce with the Linux kernel? Does anyone have an idea > on how to tackle this issue maybe?
My two cents: I think this is quite intrinsic to the flexibility of Kconfig language: IMO, it is a powerful language, but not strict enough to avoid headaches and not-so-expected results sometimes. As stated in [1]: "A config option can be defined multiple times with the same name, but every definition can have only a single input prompt and the type must not conflict." Therefore, there is nothing special in the first definition, compared to the next ones, except for the config option type initialization. With or without an input prompt. On the other hand, regarding the if/endif sections, [2] states that "the dependency expression of the if statement is appended to all enclosed menu entries". In other words, it is exactly like having a "depends on TPL" attribute under each of the config options in the if/endif TPL section. Having a single definition of each config option can help, but with some trade-offs, as you have already outlined. I remember an email from Tom about this point but I can no longer find it. Moreover, each reverse dependency, e.g. "select FOO" lines, can break the game [3]: "select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set." And "imply FOO" lines, in some ways, too. [1] https://docs.kernel.org/kbuild/kconfig-language.html#menu-entries [2] https://docs.kernel.org/kbuild/kconfig-language.html#kconfig-syntax [3] https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes To make the game even more puzzling, note that there are several nuances of dependency: we can build and run with TPL_LDSCRIPT and without TPL, therefore someone may be wonder why TPL_LDSCRIPT should depend on TPL. There are build time dependencies, run time ones, and logical ones (this is our case, here), and just one way to convey all of them at configuration level. If I am wrong, I would be happy to learn something new, of course. That said, I do not understand what exactly it is that you *really* do not want to start doing. Regards, Massimo > > Cheers, > Quentin
