[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YSQ.7.76.2002191046520.1559@knanqh.ubzr>
Date: Wed, 19 Feb 2020 11:15:57 -0500 (EST)
From: Nicolas Pitre <nico@...xnic.net>
To: Masahiro Yamada <masahiroy@...nel.org>
cc: linux-kbuild@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
Richard Cochran <richardcochran@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
John Stultz <john.stultz@...aro.org>,
Josh Triplett <josh@...htriplett.org>,
Mark Brown <broonie@...nel.org>,
Ulf Magnusson <ulfalizer@...il.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Jonathan Corbet <corbet@....net>,
Michal Marek <michal.lkml@...kovi.net>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kconfig: make 'imply' obey the direct dependency
On Wed, 19 Feb 2020, Masahiro Yamada wrote:
> The 'imply' statement may create unmet direct dependency when the
> implied symbol depends on m.
>
> [Test Code]
>
> config FOO
> tristate "foo"
> imply BAZ
>
> config BAZ
> tristate "baz"
> depends on BAR
>
> config BAR
> def_tristate m
>
> config MODULES
> def_bool y
> option modules
>
> If you set FOO=y, BAZ is also promoted to y, which results in the
> following .config file:
>
> CONFIG_FOO=y
> CONFIG_BAZ=y
> CONFIG_BAR=m
> CONFIG_MODULES=y
>
> This ignores the dependency "BAZ depends on BAR".
>
> Unlike 'select', what is worse, Kconfig never shows the
> "WARNING: unmet direct dependencies detected for ..." for this case.
>
> Because 'imply' should be weaker than 'depends on', Kconfig should
> take the direct dependency into account.
>
> Describe this case in Documentation/kbuild/kconfig-language.rst for
> clarification.
>
> Commit 237e3ad0f195 ("Kconfig: Introduce the "imply" keyword") says that
> a symbol implied by y is restricted to y or n, excluding m.
>
> As for the combination of FOO=y and BAR=m, the case of BAZ=m is excluded
> by the 'imply', and BAZ=y is also excluded by 'depends on'. So, only the
> possible value is BAZ=n.
I don't think this is right. The imply keyword provide influence over
another symbol but it should not impose any restrictions. If BAR=m then
BAZ should still be allowed to be m or n.
> @@ -174,6 +174,9 @@ applicable everywhere (see syntax).
> n y n N/m/y
> m y m M/y/n
> y y y Y/n
> + n m n N/m
> + m m m M/n
> + y m n N
Here the last line shoule be y m n N/m.
Generally speaking, the code enabled by FOO may rely on functionalities
provided by BAZ only when BAZ >= FOO. This is accomplished with
IS_REACHABLE():
foo_init()
{
if (IS_REACHABLE(CONFIG_BAZ))
baz_register(&foo);
...
}
So if FOO=y and BAZ=m then IS_REACHABLE(CONFIG_BAZ) will be false. Maybe
adding a note to that effect linked to the "y m n N/m" line in the table
would be a good idea.
Nicolas
Powered by blists - more mailing lists