On Mon, 20 Apr 2020 11:43:13 +0300 Jani Nikula wrote: > On Sun, 19 Apr 2020, Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > On Sun, Apr 19, 2020 at 4:11 AM Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > >> > >> On Sun, 19 Apr 2020, Masahiro Yamada wrote: > >> > >> > (FOO || !FOO) is difficult to understand, but > >> > the behavior of "uses FOO" is as difficult to grasp. > >> > >> Can't this be expressed as the following instead: > >> > >> depends on FOO if FOO > >> > >> That would be a little clearer. > >> > >> > >> Nicolas > > > > 'depends on' does not take the 'if <expr>' > > > > 'depends on A if B' is the syntax sugar of > > 'depends on (A || !B), right ? > > > > I do not know how clearer it would make things. > > > > depends on (m || FOO != m) > > is another equivalent, but we are always > > talking about a matter of expression. > > > > > > How important is it to stick to > > depends on (FOO || !FOO) > > or its equivalents? > > > > > > If a driver wants to use the feature FOO > > in most usecases, 'depends on FOO' is sensible. > > > > If FOO is just optional, you can get rid of the dependency, > > and IS_REACHABLE() will do logically correct things. > > If by logically correct you mean the kernel builds, you're > right. However the proliferation of IS_REACHABLE() is making the kernel > config *harder* to understand. User enables FOO=m and expects BAR to use > it, however if BAR=y it silently gets ignored. I have and I will oppose > adding IS_REACHABLE() usage to i915 because it's just silently accepting > configurations that should be flagged and forbidden at kconfig stage. +1 I wholeheartedly agree. In case of Ethernet drivers having higher layers of the stack not able to communicate with drivers is just broken IMHO.
