On Wed, Apr 08, 2020 at 10:49:48PM +0200, Arnd Bergmann wrote: > On Wed, Apr 8, 2020 at 10:38 PM Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > On Wed, 8 Apr 2020, Arnd Bergmann wrote: > > > I have created workarounds for the Kconfig files, which now stop using > > > imply and do something else in each case. I don't know whether there was > > > a bug in the kconfig changes that has led to allowing configurations that > > > were not meant to be legal even with the new semantics, or if the Kconfig > > > files have simply become incorrect now and the tool works as expected. > > > > In most cases it is the code that has to be fixed. It typically does: > > > > if (IS_ENABLED(CONFIG_FOO)) > > foo_init(); > > > > Where it should rather do: > > > > if (IS_REACHABLE(CONFIG_FOO)) > > foo_init(); > > > > A couple of such patches have been produced and queued in their > > respective trees already. > > I try to use IS_REACHABLE() only as a last resort, as it tends to > confuse users when a subsystem is built as a module and already > loaded but something relying on that subsystem does not use it. > > In the six patches I made, I had to use IS_REACHABLE() once, > for the others I tended to use a Kconfig dependency like > > 'depends on FOO || FOO=n' It is unfortunate kconfig doesn't have a language feature for this idiom, as the above is confounding without a lot of kconfig knowledge > I did come up with the IS_REACHABLE() macro originally, but that > doesn't mean I think it's a good idea to use it liberally ;-) It would be nice to have some uniform policy here I also don't like the IS_REACHABLE solution, it makes this more complicated, not less.. Jason
