[lkml]   [2018]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax
On Mon, Mar 26, 2018 at 10:29 PM, Masahiro Yamada
<> 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',
> 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]
> 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 <>

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 <>


Kees Cook
Pixel Security

 \ /
  Last update: 2018-03-28 05:34    [W:0.457 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site