Kconfig circular dependency bug?

[ninjafail]

Before opening an issue I wanted to make sure it is not intended.

The Kconifg scripts per default checks for circular dependencies and throws errors both for "depends on"-circles and "selects"-circles. However, it does not throw errors in a "depends on"-"select"-circle. I think an example illustrates this a bit better:

Given the following kconfig:

mainmenu "Cyclic Dependency Test 1"

config CyclicDep1
    depends on CyclicDep2

config CyclicDep2
    depends on CyclicDep1

When we try to parse this object using the Kconfig class from kconfiglib.py, we get a Dependency Loop error. The same would happen if we replace both "depends on" with "selects". However, when we only replace one depends on with selects, as such:

mainmenu "Cyclic Dependency Test 3"

config CyclicDep1
    depends on CyclicDep2

config CyclicDep2
    selects CyclicDep1

we can create a Kconfig object without any parsing errors, despite having a circular dependency.

As a fun exercise I checked the base Kconfig from zephyr for such loops and there exist a bunch of them. Now I'm wondering if this is intended or not?

[ldomaigne]

The answer lies in the difference between depends on and select I think?

• CyclicDep1 is only visible and selectable if CyclicDep2 is enabled (CyclicDep2=y)
• If CyclicDep2 is enabled, it will automatically enable CyclicDep1 via select (set CyclicDep1=y) regardless the CyclicDep1 dependencies.

There's no cycle, as you can see. For your specific case, this would be the same as:

config CyclicDep1
    bool "CyclicDep1 option"
    default y
    depends on CyclicDep2

config CyclicDep2
   bool "CyclicDep2 option"

Note that mixing depends on and select can lead to subtle Kconfig bug. This is explained in the Zephyr's doc on Kconfig here, and has to do with the regardless the dependencies part when using select.

[ninjafail]

Thank you for the quick reply.
I see that there is a difference but generally speaking both function like a logical implication. In the example the following holds:

• depends on: If I want to enable CyclicDep1, CyclicDep2 needs to be enabled (CyclicDep1 => CyclicDep2)
• select: If I want to enable CyclicDep2, CyclicDep1 needs to be enabled, it is just immediately enforced (CyclicDep2 => CyclicDep1)

Now your example would be the same for the cases that both symbols are the same (y/n) or only one symbol is set to y. But for the case:

CONFIG_CyclicDep1=n
CONFIG_CyclicDep2=y

they have different outputs. Using the select, both symbols get set, but using the default only CyclicDep2 is set.

I know that this is quite the technicality (and feels like nitpicking). Also generally speaking such circular dependencies can be resolved simply by setting all symbols. But what bugs me a bit is the inconsistency of the implication-cycle detection. Implication cycles for only "depends on" and only "selects" are checked but not when there is an implication cycle that contains both. 🤔

[ldomaigne]

Thanks for your explanations, I see your point. AFAICS, the behavior is a consequence of the design decision for select (selected symbol is enabled regardless to the dependency).

If CyclicDep1 depends on something, that dependency should be normally reflected in the config option that selects CyclicDep1 as explained in the select pitfalls. So:

config CyclicDep1
    depends on CyclicDep2

config CyclicDep2
    selects CyclicDep1
    depends on CyclicDep2

Then you get your dependency loop detection. I agree that this answer may not be satisfactory 😆

Coming back at your original example. Another way to look at it: CyclicDep1 and CyclicDep2 are locked , both are either enabled or disabled. We can't have some mix with one option enabled, the other disabled. This could avoid some misconfiguration.

As a fun exercise I checked the base Kconfig from zephyr for such loops and there exist a bunch of them. Now I'm wondering if this is intended or not?

Could you give a concrete example that we could investigate in more details perhaps?

[ninjafail]

Yes these are totally valid use cases. The thing that slightly bugs me then, is: Why is there a loop detection anyway? I generally don't really see how cycles could make problems as they can just be satisfied by enabling all symbols. As you said, they basically lock symbols together. Do you know the reason why it is forbidden to create pure "depends on"-cycles and pure "selects"-cycles?

I don't think we need to go into the examples. After making the results of my script actually usable, I looked into most of them it seems like they couldn't cause any problems. One example would be NET_L2_ETHERNET => WIFI_NRF70 => NET_L2_ETHERNET_MGMT => NET_L2_ETHERNET:

• In drivers/wifi/nrf_wifi/Kconfig.nrfwifi:66, NET_L2_ETHERNET is defined inside of the if block of WIFI_NRF70
• Then in drivers/wifi/nrf_wifi/Kconfig.nrfwifi:8, WIFI_NRF70 selects NET_L2_ETHERNET_MGMT (but only if NET_L2_ETHERNET)
• Then finally in subsys/net/l2/ethernet/Kconfig:27, NET_L2_ETHERNET_MGMT is defined inside of the NET_L2_ETHERNET if block.

Going through that example, there shouldn't be a problem, as WIFI_NRF70 selects NET_L2_ETHERNET_MGMT (which is dependent on NET_L2_ETHERNET) only if NET_L2_ETHERNET is already enabled. Others include loops between 2 symbols, meaning they are just "locked".

I put all the cycles my script found into the attachment: cycles.json (I ran my script on v4.1.0)

Sorry for the inconvenience. I thought maybe there is something behind that inconsistency that I stumbled upon during my master thesis but I guess its fine 🤷.

[ldomaigne]

Yes these are totally valid use cases. The thing that slightly bugs me then, is: Why is there a loop detection anyway? Do you know the reason why it is forbidden to create pure "depends on"-cycles and pure "selects"-cycles?

From what I can see, the loop detection is needed as part of the recursive descent through the dependency tree. Quoting @ulfalizer from this thread:

There isn't any fancy SAT stuff going on internally btw, just (recursive) evaluation of symbols.

The only slightly tricky part is that symbol values must be cached (and invalidated), or you go into exponential times for some stuff.

This keeps the solver simple, at the expense of a more complex Kconfig trees maintenance.

generally don't really see how cycles could make problems as they can just be satisfied by enabling all symbols.

See this answer

Sorry for the inconvenience. I thought maybe there is something behind that inconsistency that I stumbled upon during my master thesis but I guess its fine 🤷.

Thank you for your question! It was an opportunity to dive deeper into Kconfig. select was meant for non-visible symbols and for symbols with no dependencies. This is used otherwise, with the risks of getting illegal configurations when not loop. So, your checks/queries make perfectly sense!

P.S.> If you still need some deeper answers, suggest to contact Ulf.

[ninjafail]

Thank you very much for all those insights and your time! I learned a lot :)