On Fri, May 20, 2022 at 11:13 AM Daniel Latypov dlatypov@google.com wrote:
On Thu, May 19, 2022 at 11:13 PM David Gow davidgow@google.com wrote:
I like this, but do think there are a few gaps this doesn't handle properly. (Though exactly how we'd deal with them, I'm not yet sure.)
In particular, it's not possible to disable a pair of options where one depends on the other: disabling the parent option will result in the child one not being present in the generated config. This will conflict both with "=y" and "=n/not set": we'd need a way to _remove_ a kconfig option for that to work.
Do you have an example? Because what you describe sounds like how we want it to work, but I'm not sure if I'm misunderstanding the scenario you describe.
Talking offline with David, we've come up with a small example.
If we add this kconfig somewhere +config X + bool "X" + default y + +config Y + bool "Y" + default y + depends on X +
Then running this will fail $ ./tools/testing/kunit/kunit.py config --kunitconfig xy_kunitconfig --kconfig_add=CONFIG_X=n --kconfig_add=CONFIG_Y=n
It will fail with this This is probably due to unsatisfied dependencies. Missing: # CONFIG_Y is not set
The problem is that kunit.py is looking for an explicit line saying CONFIG_Y is not set. But CONFIG_Y's dependencies are not met, so Kconfig doesn't write it out.
I assume we can treat the absence of it in the file as proof that it's not set. I.e. the bug lies in the is_subset() logic we have in kunit.py?
I think there's also a general problem with kunit.py/kunitconfig not really handling disabling options properly.