On Fri, May 20, 2022 at 11:13 AM Daniel Latypov <dlatypov@xxxxxxxxxx> wrote: > > On Thu, May 19, 2022 at 11:13 PM David Gow <davidgow@xxxxxxxxxx> 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.
