Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax
From: Kees Cook
Date: Tue Mar 27 2018 - 23:34:02 EST
On Mon, Mar 26, 2018 at 10:29 PM, Masahiro Yamada
<yamada.masahiro@xxxxxxxxxxxxx> wrote:
> To get an environment value, Kconfig needs to define a symbol using
> "option env=" syntax. It is tedious to add a config entry for each
> environment given that we need more environments such as 'CC', 'AS',
> 'srctree' etc. to evaluate the compiler capability in Kconfig.
>
> Adding '$' to symbols is weird. Kconfig can reference symbols directly
> like this:
>
> config FOO
> string
> default BAR
>
> So, I want to use the following syntax to get environment 'BAR' from
> the system:
>
> config FOO
> string
> default $BAR
>
> Looking at the code, the symbols prefixed with 'S' are expanded by:
> - conf_expand_value()
> This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
> - expand_string_value()
> This is used to expand strings in 'source' and 'mainmenu'
>
> All of them are fixed values independent of user configuration. So,
> this kind of syntax should be moved to simply take the environment.
>
> This change makes the code much cleaner. The bounce symbols 'SRCARCH',
> 'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.
>
> sym_init() hard-coding 'UNAME_RELEASE' is also gone. 'UNAME_RELEASE'
> should be be given from the environment.
>
> ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
> by 'default ARCH_DEFCONFIG'.
>
> The environments are expanding in the lexer; when '$' is encountered,
> it is expanded, and resulted strings are pushed back to the input
> stream. This makes the implementation simpler.
>
> For example, the following code works.
>
> [Example code]
>
> config TOOLCHAIN_LIST
> string
> default "My tools: CC=$CC, AS=$AS, CPP=$CPP"
>
> [Result]
>
> $ make -s alldefconfig && tail -n 1 .config
> CONFIG_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
For easier review this patch could maybe get split into a couple (i.e.
refactoring of things like env_write_dep()) but it's probably fine
as-is. :)
Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>
-Kees
--
Kees Cook
Pixel Security