Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Ulf Magnusson]

On Tue, Apr 17, 2018 at 5:07 PM, Masahiro Yamada
 wrote:
> 2018-04-15 17:08 GMT+09:00 Ulf Magnusson :
>> On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
>>  wrote:
>>> Add a document for the macro language introduced to Kconfig.
>>>
>>> The motivation of this work is to move the compiler option tests to
>>> Kconfig from Makefile.  A number of kernel features require the
>>> compiler support.  Enabling such features blindly in Kconfig ends up
>>> with a lot of nasty build-time testing in Makefiles.  If a chosen
>>> feature turns out unsupported by the compiler, what the build system
>>> can do is either to disable it (silently!) or to forcibly break the
>>> build, despite Kconfig has let the user to enable it.
>>>
>>> This change was strongly prompted by Linus Torvalds.  You can find
>>> his suggestions [1] [2] in ML.  The original idea was to add a new
>>> 'option', but I found generalized text expansion would make Kconfig
>>> more powerful and lovely.  While polishing up the implementation, I
>>> noticed sort of similarity between Make and Kconfig.  This might be
>>> too immature to be called 'language', but anyway here it is.  All
>>> ideas are from Make (you can even say it is addicted), so people
>>> will easily understand how it works.
>>>
>>> [1]: https://lkml.org/lkml/2016/12/9/577
>>> [2]: https://lkml.org/lkml/2018/2/7/527
>>>
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>> Changes in v3: None
>>> Changes in v2: None
>>>
>>>  Documentation/kbuild/kconfig-macro-language.txt | 179 
>>> 
>>>  MAINTAINERS |   2 +-
>>>  2 files changed, 180 insertions(+), 1 deletion(-)
>>>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>>>
>>> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
>>> b/Documentation/kbuild/kconfig-macro-language.txt
>>> new file mode 100644
>>> index 000..1f6281b
>>> --- /dev/null
>>> +++ b/Documentation/kbuild/kconfig-macro-language.txt
>>> @@ -0,0 +1,179 @@
>>> +Concept
>>> +---
>>> +
>>> +The basic idea was inspired by Make. When we look at Make, we notice sort 
>>> of
>>> +two languages in one. One language describes dependency graphs consisting 
>>> of
>>> +targets and prerequisites. The other is a macro language for performing 
>>> textual
>>> +substitution.
>>> +
>>> +There is clear distinction between the two language stages. For example, 
>>> you
>>> +can write a makefile like follows:
>>> +
>>> +APP := foo
>>> +SRC := foo.c
>>> +CC := gcc
>>> +
>>> +$(APP): $(SRC)
>>> +$(CC) -o $(APP) $(SRC)
>>> +
>>> +The macro language replaces the variable references with their expanded 
>>> form,
>>> +and handles as if the source file were input like follows:
>>> +
>>> +foo: foo.c
>>> +gcc -o foo foo.c
>>> +
>>> +Then, Make analyzes the dependency graph and determines the targets to be
>>> +updated.
>>> +
>>> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
>>> +file like this:
>>> +
>>> +CC := gcc
>>> +
>>> +config CC_HAS_FOO
>>> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
>>> +
>>> +The macro language in Kconfig processes the source file into the following
>>> +intermediate:
>>> +
>>> +config CC_HAS_FOO
>>> +def_bool y
>>> +
>>> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
>>> +dependency, which is explained in kconfig-language.txt.
>>> +
>>> +
>>> +Variables
>>> +-
>>> +
>>> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
>>> +variable is expanded "in place" to yield a text string that may then 
>>> expanded
>>> +further. To get the value of a variable, enclose the variable name in $( ).
>>> +As a special case, single-letter variable names can omit the parentheses 
>>> and is
>>> +simply referenced like $X. Unlike Make, Kconfig does not support curly 
>>> braces
>>> +as in ${CC}.
>>
>> Do we need single-letter variable names for anything? It looks like
>> we're deviating
>> a bit from Make behavior already.
>>
>> I suspect they're just a side effect of Make having automatic variables like 
>> $@.
>> The Make manual discourages them otherwise:
>>
>> "A dollar sign followed by a character other than a dollar sign,
>> open-parenthesis or
>> open-brace treats that single character as the variable name. Thus, you could
>> reference the variable x with `$x'. However, this practice is strongly
>> discouraged,
>> except in the case of the automatic variables (see section Automatic
>> Variables)."
>>
>
> OK.  We do not need two ways to do the same thing.
>
> I will consider it
> although supporting single-letter variable is not costly.
>
>
>
> --
> Best Regards
> Masahiro Yamada

Can you think of any cases where dynamic generation of Kconfig symbol
names would be a good solution by the way?

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Ulf Magnusson]

On Tue, Apr 17, 2018 at 5:07 PM, Masahiro Yamada
 wrote:
> 2018-04-15 17:08 GMT+09:00 Ulf Magnusson :
>> On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
>>  wrote:
>>> Add a document for the macro language introduced to Kconfig.
>>>
>>> The motivation of this work is to move the compiler option tests to
>>> Kconfig from Makefile.  A number of kernel features require the
>>> compiler support.  Enabling such features blindly in Kconfig ends up
>>> with a lot of nasty build-time testing in Makefiles.  If a chosen
>>> feature turns out unsupported by the compiler, what the build system
>>> can do is either to disable it (silently!) or to forcibly break the
>>> build, despite Kconfig has let the user to enable it.
>>>
>>> This change was strongly prompted by Linus Torvalds.  You can find
>>> his suggestions [1] [2] in ML.  The original idea was to add a new
>>> 'option', but I found generalized text expansion would make Kconfig
>>> more powerful and lovely.  While polishing up the implementation, I
>>> noticed sort of similarity between Make and Kconfig.  This might be
>>> too immature to be called 'language', but anyway here it is.  All
>>> ideas are from Make (you can even say it is addicted), so people
>>> will easily understand how it works.
>>>
>>> [1]: https://lkml.org/lkml/2016/12/9/577
>>> [2]: https://lkml.org/lkml/2018/2/7/527
>>>
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>> Changes in v3: None
>>> Changes in v2: None
>>>
>>>  Documentation/kbuild/kconfig-macro-language.txt | 179 
>>> 
>>>  MAINTAINERS |   2 +-
>>>  2 files changed, 180 insertions(+), 1 deletion(-)
>>>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>>>
>>> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
>>> b/Documentation/kbuild/kconfig-macro-language.txt
>>> new file mode 100644
>>> index 000..1f6281b
>>> --- /dev/null
>>> +++ b/Documentation/kbuild/kconfig-macro-language.txt
>>> @@ -0,0 +1,179 @@
>>> +Concept
>>> +---
>>> +
>>> +The basic idea was inspired by Make. When we look at Make, we notice sort 
>>> of
>>> +two languages in one. One language describes dependency graphs consisting 
>>> of
>>> +targets and prerequisites. The other is a macro language for performing 
>>> textual
>>> +substitution.
>>> +
>>> +There is clear distinction between the two language stages. For example, 
>>> you
>>> +can write a makefile like follows:
>>> +
>>> +APP := foo
>>> +SRC := foo.c
>>> +CC := gcc
>>> +
>>> +$(APP): $(SRC)
>>> +$(CC) -o $(APP) $(SRC)
>>> +
>>> +The macro language replaces the variable references with their expanded 
>>> form,
>>> +and handles as if the source file were input like follows:
>>> +
>>> +foo: foo.c
>>> +gcc -o foo foo.c
>>> +
>>> +Then, Make analyzes the dependency graph and determines the targets to be
>>> +updated.
>>> +
>>> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
>>> +file like this:
>>> +
>>> +CC := gcc
>>> +
>>> +config CC_HAS_FOO
>>> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
>>> +
>>> +The macro language in Kconfig processes the source file into the following
>>> +intermediate:
>>> +
>>> +config CC_HAS_FOO
>>> +def_bool y
>>> +
>>> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
>>> +dependency, which is explained in kconfig-language.txt.
>>> +
>>> +
>>> +Variables
>>> +-
>>> +
>>> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
>>> +variable is expanded "in place" to yield a text string that may then 
>>> expanded
>>> +further. To get the value of a variable, enclose the variable name in $( ).
>>> +As a special case, single-letter variable names can omit the parentheses 
>>> and is
>>> +simply referenced like $X. Unlike Make, Kconfig does not support curly 
>>> braces
>>> +as in ${CC}.
>>
>> Do we need single-letter variable names for anything? It looks like
>> we're deviating
>> a bit from Make behavior already.
>>
>> I suspect they're just a side effect of Make having automatic variables like 
>> $@.
>> The Make manual discourages them otherwise:
>>
>> "A dollar sign followed by a character other than a dollar sign,
>> open-parenthesis or
>> open-brace treats that single character as the variable name. Thus, you could
>> reference the variable x with `$x'. However, this practice is strongly
>> discouraged,
>> except in the case of the automatic variables (see section Automatic
>> Variables)."
>>
>
> OK.  We do not need two ways to do the same thing.
>
> I will consider it
> although supporting single-letter variable is not costly.
>
>
>
> --
> Best Regards
> Masahiro Yamada

Can you think of any cases where dynamic generation of Kconfig symbol
names would be a good solution by the way?

Personally, I'd make the semantics obvious by requiring quotes, so you
could do e.g.

bar := "bar value"
baz := 

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Masahiro Yamada]

2018-04-15 17:08 GMT+09:00 Ulf Magnusson :
> On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
>  wrote:
>> Add a document for the macro language introduced to Kconfig.
>>
>> The motivation of this work is to move the compiler option tests to
>> Kconfig from Makefile.  A number of kernel features require the
>> compiler support.  Enabling such features blindly in Kconfig ends up
>> with a lot of nasty build-time testing in Makefiles.  If a chosen
>> feature turns out unsupported by the compiler, what the build system
>> can do is either to disable it (silently!) or to forcibly break the
>> build, despite Kconfig has let the user to enable it.
>>
>> This change was strongly prompted by Linus Torvalds.  You can find
>> his suggestions [1] [2] in ML.  The original idea was to add a new
>> 'option', but I found generalized text expansion would make Kconfig
>> more powerful and lovely.  While polishing up the implementation, I
>> noticed sort of similarity between Make and Kconfig.  This might be
>> too immature to be called 'language', but anyway here it is.  All
>> ideas are from Make (you can even say it is addicted), so people
>> will easily understand how it works.
>>
>> [1]: https://lkml.org/lkml/2016/12/9/577
>> [2]: https://lkml.org/lkml/2018/2/7/527
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>  Documentation/kbuild/kconfig-macro-language.txt | 179 
>> 
>>  MAINTAINERS |   2 +-
>>  2 files changed, 180 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>>
>> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
>> b/Documentation/kbuild/kconfig-macro-language.txt
>> new file mode 100644
>> index 000..1f6281b
>> --- /dev/null
>> +++ b/Documentation/kbuild/kconfig-macro-language.txt
>> @@ -0,0 +1,179 @@
>> +Concept
>> +---
>> +
>> +The basic idea was inspired by Make. When we look at Make, we notice sort of
>> +two languages in one. One language describes dependency graphs consisting of
>> +targets and prerequisites. The other is a macro language for performing 
>> textual
>> +substitution.
>> +
>> +There is clear distinction between the two language stages. For example, you
>> +can write a makefile like follows:
>> +
>> +APP := foo
>> +SRC := foo.c
>> +CC := gcc
>> +
>> +$(APP): $(SRC)
>> +$(CC) -o $(APP) $(SRC)
>> +
>> +The macro language replaces the variable references with their expanded 
>> form,
>> +and handles as if the source file were input like follows:
>> +
>> +foo: foo.c
>> +gcc -o foo foo.c
>> +
>> +Then, Make analyzes the dependency graph and determines the targets to be
>> +updated.
>> +
>> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
>> +file like this:
>> +
>> +CC := gcc
>> +
>> +config CC_HAS_FOO
>> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
>> +
>> +The macro language in Kconfig processes the source file into the following
>> +intermediate:
>> +
>> +config CC_HAS_FOO
>> +def_bool y
>> +
>> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
>> +dependency, which is explained in kconfig-language.txt.
>> +
>> +
>> +Variables
>> +-
>> +
>> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
>> +variable is expanded "in place" to yield a text string that may then 
>> expanded
>> +further. To get the value of a variable, enclose the variable name in $( ).
>> +As a special case, single-letter variable names can omit the parentheses 
>> and is
>> +simply referenced like $X. Unlike Make, Kconfig does not support curly 
>> braces
>> +as in ${CC}.
>
> Do we need single-letter variable names for anything? It looks like
> we're deviating
> a bit from Make behavior already.
>
> I suspect they're just a side effect of Make having automatic variables like 
> $@.
> The Make manual discourages them otherwise:
>
> "A dollar sign followed by a character other than a dollar sign,
> open-parenthesis or
> open-brace treats that single character as the variable name. Thus, you could
> reference the variable x with `$x'. However, this practice is strongly
> discouraged,
> except in the case of the automatic variables (see section Automatic
> Variables)."
>

OK.  We do not need two ways to do the same thing.

I will consider it
although supporting single-letter variable is not costly.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Masahiro Yamada]

2018-04-15 17:08 GMT+09:00 Ulf Magnusson :
> On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
>  wrote:
>> Add a document for the macro language introduced to Kconfig.
>>
>> The motivation of this work is to move the compiler option tests to
>> Kconfig from Makefile.  A number of kernel features require the
>> compiler support.  Enabling such features blindly in Kconfig ends up
>> with a lot of nasty build-time testing in Makefiles.  If a chosen
>> feature turns out unsupported by the compiler, what the build system
>> can do is either to disable it (silently!) or to forcibly break the
>> build, despite Kconfig has let the user to enable it.
>>
>> This change was strongly prompted by Linus Torvalds.  You can find
>> his suggestions [1] [2] in ML.  The original idea was to add a new
>> 'option', but I found generalized text expansion would make Kconfig
>> more powerful and lovely.  While polishing up the implementation, I
>> noticed sort of similarity between Make and Kconfig.  This might be
>> too immature to be called 'language', but anyway here it is.  All
>> ideas are from Make (you can even say it is addicted), so people
>> will easily understand how it works.
>>
>> [1]: https://lkml.org/lkml/2016/12/9/577
>> [2]: https://lkml.org/lkml/2018/2/7/527
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>  Documentation/kbuild/kconfig-macro-language.txt | 179 
>> 
>>  MAINTAINERS |   2 +-
>>  2 files changed, 180 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>>
>> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
>> b/Documentation/kbuild/kconfig-macro-language.txt
>> new file mode 100644
>> index 000..1f6281b
>> --- /dev/null
>> +++ b/Documentation/kbuild/kconfig-macro-language.txt
>> @@ -0,0 +1,179 @@
>> +Concept
>> +---
>> +
>> +The basic idea was inspired by Make. When we look at Make, we notice sort of
>> +two languages in one. One language describes dependency graphs consisting of
>> +targets and prerequisites. The other is a macro language for performing 
>> textual
>> +substitution.
>> +
>> +There is clear distinction between the two language stages. For example, you
>> +can write a makefile like follows:
>> +
>> +APP := foo
>> +SRC := foo.c
>> +CC := gcc
>> +
>> +$(APP): $(SRC)
>> +$(CC) -o $(APP) $(SRC)
>> +
>> +The macro language replaces the variable references with their expanded 
>> form,
>> +and handles as if the source file were input like follows:
>> +
>> +foo: foo.c
>> +gcc -o foo foo.c
>> +
>> +Then, Make analyzes the dependency graph and determines the targets to be
>> +updated.
>> +
>> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
>> +file like this:
>> +
>> +CC := gcc
>> +
>> +config CC_HAS_FOO
>> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
>> +
>> +The macro language in Kconfig processes the source file into the following
>> +intermediate:
>> +
>> +config CC_HAS_FOO
>> +def_bool y
>> +
>> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
>> +dependency, which is explained in kconfig-language.txt.
>> +
>> +
>> +Variables
>> +-
>> +
>> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
>> +variable is expanded "in place" to yield a text string that may then 
>> expanded
>> +further. To get the value of a variable, enclose the variable name in $( ).
>> +As a special case, single-letter variable names can omit the parentheses 
>> and is
>> +simply referenced like $X. Unlike Make, Kconfig does not support curly 
>> braces
>> +as in ${CC}.
>
> Do we need single-letter variable names for anything? It looks like
> we're deviating
> a bit from Make behavior already.
>
> I suspect they're just a side effect of Make having automatic variables like 
> $@.
> The Make manual discourages them otherwise:
>
> "A dollar sign followed by a character other than a dollar sign,
> open-parenthesis or
> open-brace treats that single character as the variable name. Thus, you could
> reference the variable x with `$x'. However, this practice is strongly
> discouraged,
> except in the case of the automatic variables (see section Automatic
> Variables)."
>

OK.  We do not need two ways to do the same thing.

I will consider it
although supporting single-letter variable is not costly.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Masahiro Yamada]

2018-04-15 8:33 GMT+09:00 Randy Dunlap :
> On 04/12/18 22:06, Masahiro Yamada wrote:
>> Add a document for the macro language introduced to Kconfig.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>  Documentation/kbuild/kconfig-macro-language.txt | 179 
>> 
>>  MAINTAINERS |   2 +-
>>  2 files changed, 180 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>>
>> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
>> b/Documentation/kbuild/kconfig-macro-language.txt
>> new file mode 100644
>> index 000..1f6281b
>> --- /dev/null
>> +++ b/Documentation/kbuild/kconfig-macro-language.txt
>> @@ -0,0 +1,179 @@
>> +Concept
>> +---
>> +
>> +The basic idea was inspired by Make. When we look at Make, we notice sort of
>> +two languages in one. One language describes dependency graphs consisting of
>> +targets and prerequisites. The other is a macro language for performing 
>> textual
>> +substitution.
>> +
>> +There is clear distinction between the two language stages. For example, you
>> +can write a makefile like follows:
>> +
>> +APP := foo
>> +SRC := foo.c
>> +CC := gcc
>> +
>> +$(APP): $(SRC)
>> +$(CC) -o $(APP) $(SRC)
>> +
>> +The macro language replaces the variable references with their expanded 
>> form,
>> +and handles as if the source file were input like follows:
>> +
>> +foo: foo.c
>> +gcc -o foo foo.c
>> +
>> +Then, Make analyzes the dependency graph and determines the targets to be
>> +updated.
>> +
>> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
>> +file like this:
>> +
>> +CC := gcc
>> +
>> +config CC_HAS_FOO
>> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
>> +
>> +The macro language in Kconfig processes the source file into the following
>> +intermediate:
>> +
>> +config CC_HAS_FOO
>> +def_bool y
>> +
>> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
>> +dependency, which is explained in kconfig-language.txt.
>> +
>> +
>> +Variables
>> +-
>> +
>> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
>> +variable is expanded "in place" to yield a text string that may then 
>> expanded
>
>may then be 
> expanded
>
>> +further. To get the value of a variable, enclose the variable name in $( ).
>> +As a special case, single-letter variable names can omit the parentheses 
>> and is
>
> 
> and are
>
>> +simply referenced like $X. Unlike Make, Kconfig does not support curly 
>> braces
>> +as in ${CC}.
>> +
>> +There are two types of variables: simply expanded variables and recursively
>> +expanded variables.
>> +
>> +A simply expanded variable is defined using the := assignment operator. Its
>> +righthand side is expanded immediately upon reading the line from the 
>> Kconfig
>> +file.
>> +
>> +A recursively expanded variable is defined using the = assignment operator.
>> +Its righthand side is simply stored as the value of the variable without
>> +expanding it in any way. Instead, the expansion is performed when the 
>> variable
>> +is used.
>> +
>> +There is another type of assignment operator; += is used to append text to a
>> +variable. The righthand side of += is expanded immediately if the lefthand
>> +side was originally defined as a simple variable. Otherwise, its evaluation 
>> is
>> +deferred.
>> +
>> +
>> +Functions
>> +-
>> +
>> +Like Make, Kconfig supports both built-in and user-defined functions. A
>> +function invocation looks much like a variable reference, but includes one 
>> or
>> +more parameters separated by commas:
>> +
>> +  $(function-name arg1, arg2, arg3)
>> +
>> +Some functions are implemented as a built-in function. Currently, Kconfig
>> +supports the following:
>> +
>> + - $(shell command)
>> +
>> +  The 'shell' function accepts a single argument that is expanded and passed
>> +  to a subshell for execution. The standard output of the command is then 
>> read
>> +  and returned as the value of the function. Every newline in the output is
>> +  replaced with a space. Any trailing newlines are deleted. The standard 
>> error
>> +  is not returned, nor is any program exit status.
>> +
>> + - $(warning text)
>> +
>> +  The 'warning' function prints its arguments to stderr. The output is 
>> prefixed
>> +  with the name of the current Kconfig file, the current line number. It
>
>   file and the current line number. It
>
>> +  evaluates to an empty string.
>> +
>> + - $(info text)
>> +
>> +  The 'info' function is similar to 'warning' except that it sends its 
>> argument
>> +  to stdout without 

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Masahiro Yamada]

2018-04-15 8:33 GMT+09:00 Randy Dunlap :
> On 04/12/18 22:06, Masahiro Yamada wrote:
>> Add a document for the macro language introduced to Kconfig.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>  Documentation/kbuild/kconfig-macro-language.txt | 179 
>> 
>>  MAINTAINERS |   2 +-
>>  2 files changed, 180 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>>
>> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
>> b/Documentation/kbuild/kconfig-macro-language.txt
>> new file mode 100644
>> index 000..1f6281b
>> --- /dev/null
>> +++ b/Documentation/kbuild/kconfig-macro-language.txt
>> @@ -0,0 +1,179 @@
>> +Concept
>> +---
>> +
>> +The basic idea was inspired by Make. When we look at Make, we notice sort of
>> +two languages in one. One language describes dependency graphs consisting of
>> +targets and prerequisites. The other is a macro language for performing 
>> textual
>> +substitution.
>> +
>> +There is clear distinction between the two language stages. For example, you
>> +can write a makefile like follows:
>> +
>> +APP := foo
>> +SRC := foo.c
>> +CC := gcc
>> +
>> +$(APP): $(SRC)
>> +$(CC) -o $(APP) $(SRC)
>> +
>> +The macro language replaces the variable references with their expanded 
>> form,
>> +and handles as if the source file were input like follows:
>> +
>> +foo: foo.c
>> +gcc -o foo foo.c
>> +
>> +Then, Make analyzes the dependency graph and determines the targets to be
>> +updated.
>> +
>> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
>> +file like this:
>> +
>> +CC := gcc
>> +
>> +config CC_HAS_FOO
>> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
>> +
>> +The macro language in Kconfig processes the source file into the following
>> +intermediate:
>> +
>> +config CC_HAS_FOO
>> +def_bool y
>> +
>> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
>> +dependency, which is explained in kconfig-language.txt.
>> +
>> +
>> +Variables
>> +-
>> +
>> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
>> +variable is expanded "in place" to yield a text string that may then 
>> expanded
>
>may then be 
> expanded
>
>> +further. To get the value of a variable, enclose the variable name in $( ).
>> +As a special case, single-letter variable names can omit the parentheses 
>> and is
>
> 
> and are
>
>> +simply referenced like $X. Unlike Make, Kconfig does not support curly 
>> braces
>> +as in ${CC}.
>> +
>> +There are two types of variables: simply expanded variables and recursively
>> +expanded variables.
>> +
>> +A simply expanded variable is defined using the := assignment operator. Its
>> +righthand side is expanded immediately upon reading the line from the 
>> Kconfig
>> +file.
>> +
>> +A recursively expanded variable is defined using the = assignment operator.
>> +Its righthand side is simply stored as the value of the variable without
>> +expanding it in any way. Instead, the expansion is performed when the 
>> variable
>> +is used.
>> +
>> +There is another type of assignment operator; += is used to append text to a
>> +variable. The righthand side of += is expanded immediately if the lefthand
>> +side was originally defined as a simple variable. Otherwise, its evaluation 
>> is
>> +deferred.
>> +
>> +
>> +Functions
>> +-
>> +
>> +Like Make, Kconfig supports both built-in and user-defined functions. A
>> +function invocation looks much like a variable reference, but includes one 
>> or
>> +more parameters separated by commas:
>> +
>> +  $(function-name arg1, arg2, arg3)
>> +
>> +Some functions are implemented as a built-in function. Currently, Kconfig
>> +supports the following:
>> +
>> + - $(shell command)
>> +
>> +  The 'shell' function accepts a single argument that is expanded and passed
>> +  to a subshell for execution. The standard output of the command is then 
>> read
>> +  and returned as the value of the function. Every newline in the output is
>> +  replaced with a space. Any trailing newlines are deleted. The standard 
>> error
>> +  is not returned, nor is any program exit status.
>> +
>> + - $(warning text)
>> +
>> +  The 'warning' function prints its arguments to stderr. The output is 
>> prefixed
>> +  with the name of the current Kconfig file, the current line number. It
>
>   file and the current line number. It
>
>> +  evaluates to an empty string.
>> +
>> + - $(info text)
>> +
>> +  The 'info' function is similar to 'warning' except that it sends its 
>> argument
>> +  to stdout without any Kconfig name or line number.
>
> Are current 

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Ulf Magnusson]

On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
 wrote:
> Add a document for the macro language introduced to Kconfig.
>
> The motivation of this work is to move the compiler option tests to
> Kconfig from Makefile.  A number of kernel features require the
> compiler support.  Enabling such features blindly in Kconfig ends up
> with a lot of nasty build-time testing in Makefiles.  If a chosen
> feature turns out unsupported by the compiler, what the build system
> can do is either to disable it (silently!) or to forcibly break the
> build, despite Kconfig has let the user to enable it.
>
> This change was strongly prompted by Linus Torvalds.  You can find
> his suggestions [1] [2] in ML.  The original idea was to add a new
> 'option', but I found generalized text expansion would make Kconfig
> more powerful and lovely.  While polishing up the implementation, I
> noticed sort of similarity between Make and Kconfig.  This might be
> too immature to be called 'language', but anyway here it is.  All
> ideas are from Make (you can even say it is addicted), so people
> will easily understand how it works.
>
> [1]: https://lkml.org/lkml/2016/12/9/577
> [2]: https://lkml.org/lkml/2018/2/7/527
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  Documentation/kbuild/kconfig-macro-language.txt | 179 
> 
>  MAINTAINERS |   2 +-
>  2 files changed, 180 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>
> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
> b/Documentation/kbuild/kconfig-macro-language.txt
> new file mode 100644
> index 000..1f6281b
> --- /dev/null
> +++ b/Documentation/kbuild/kconfig-macro-language.txt
> @@ -0,0 +1,179 @@
> +Concept
> +---
> +
> +The basic idea was inspired by Make. When we look at Make, we notice sort of
> +two languages in one. One language describes dependency graphs consisting of
> +targets and prerequisites. The other is a macro language for performing 
> textual
> +substitution.
> +
> +There is clear distinction between the two language stages. For example, you
> +can write a makefile like follows:
> +
> +APP := foo
> +SRC := foo.c
> +CC := gcc
> +
> +$(APP): $(SRC)
> +$(CC) -o $(APP) $(SRC)
> +
> +The macro language replaces the variable references with their expanded form,
> +and handles as if the source file were input like follows:
> +
> +foo: foo.c
> +gcc -o foo foo.c
> +
> +Then, Make analyzes the dependency graph and determines the targets to be
> +updated.
> +
> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
> +file like this:
> +
> +CC := gcc
> +
> +config CC_HAS_FOO
> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
> +
> +The macro language in Kconfig processes the source file into the following
> +intermediate:
> +
> +config CC_HAS_FOO
> +def_bool y
> +
> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
> +dependency, which is explained in kconfig-language.txt.
> +
> +
> +Variables
> +-
> +
> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
> +variable is expanded "in place" to yield a text string that may then expanded
> +further. To get the value of a variable, enclose the variable name in $( ).
> +As a special case, single-letter variable names can omit the parentheses and 
> is
> +simply referenced like $X. Unlike Make, Kconfig does not support curly braces
> +as in ${CC}.

Do we need single-letter variable names for anything? It looks like
we're deviating
a bit from Make behavior already.

I suspect they're just a side effect of Make having automatic variables like $@.
The Make manual discourages them otherwise:

"A dollar sign followed by a character other than a dollar sign,
open-parenthesis or
open-brace treats that single character as the variable name. Thus, you could
reference the variable x with `$x'. However, this practice is strongly
discouraged,
except in the case of the automatic variables (see section Automatic
Variables)."

Cheers,
Ulf

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Ulf Magnusson]

On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
 wrote:
> Add a document for the macro language introduced to Kconfig.
>
> The motivation of this work is to move the compiler option tests to
> Kconfig from Makefile.  A number of kernel features require the
> compiler support.  Enabling such features blindly in Kconfig ends up
> with a lot of nasty build-time testing in Makefiles.  If a chosen
> feature turns out unsupported by the compiler, what the build system
> can do is either to disable it (silently!) or to forcibly break the
> build, despite Kconfig has let the user to enable it.
>
> This change was strongly prompted by Linus Torvalds.  You can find
> his suggestions [1] [2] in ML.  The original idea was to add a new
> 'option', but I found generalized text expansion would make Kconfig
> more powerful and lovely.  While polishing up the implementation, I
> noticed sort of similarity between Make and Kconfig.  This might be
> too immature to be called 'language', but anyway here it is.  All
> ideas are from Make (you can even say it is addicted), so people
> will easily understand how it works.
>
> [1]: https://lkml.org/lkml/2016/12/9/577
> [2]: https://lkml.org/lkml/2018/2/7/527
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  Documentation/kbuild/kconfig-macro-language.txt | 179 
> 
>  MAINTAINERS |   2 +-
>  2 files changed, 180 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>
> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
> b/Documentation/kbuild/kconfig-macro-language.txt
> new file mode 100644
> index 000..1f6281b
> --- /dev/null
> +++ b/Documentation/kbuild/kconfig-macro-language.txt
> @@ -0,0 +1,179 @@
> +Concept
> +---
> +
> +The basic idea was inspired by Make. When we look at Make, we notice sort of
> +two languages in one. One language describes dependency graphs consisting of
> +targets and prerequisites. The other is a macro language for performing 
> textual
> +substitution.
> +
> +There is clear distinction between the two language stages. For example, you
> +can write a makefile like follows:
> +
> +APP := foo
> +SRC := foo.c
> +CC := gcc
> +
> +$(APP): $(SRC)
> +$(CC) -o $(APP) $(SRC)
> +
> +The macro language replaces the variable references with their expanded form,
> +and handles as if the source file were input like follows:
> +
> +foo: foo.c
> +gcc -o foo foo.c
> +
> +Then, Make analyzes the dependency graph and determines the targets to be
> +updated.
> +
> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
> +file like this:
> +
> +CC := gcc
> +
> +config CC_HAS_FOO
> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
> +
> +The macro language in Kconfig processes the source file into the following
> +intermediate:
> +
> +config CC_HAS_FOO
> +def_bool y
> +
> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
> +dependency, which is explained in kconfig-language.txt.
> +
> +
> +Variables
> +-
> +
> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
> +variable is expanded "in place" to yield a text string that may then expanded
> +further. To get the value of a variable, enclose the variable name in $( ).
> +As a special case, single-letter variable names can omit the parentheses and 
> is
> +simply referenced like $X. Unlike Make, Kconfig does not support curly braces
> +as in ${CC}.

Do we need single-letter variable names for anything? It looks like
we're deviating
a bit from Make behavior already.

I suspect they're just a side effect of Make having automatic variables like $@.
The Make manual discourages them otherwise:

"A dollar sign followed by a character other than a dollar sign,
open-parenthesis or
open-brace treats that single character as the variable name. Thus, you could
reference the variable x with `$x'. However, this practice is strongly
discouraged,
except in the case of the automatic variables (see section Automatic
Variables)."

Cheers,
Ulf

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Randy Dunlap]

On 04/12/18 22:06, Masahiro Yamada wrote:
> Add a document for the macro language introduced to Kconfig.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/kbuild/kconfig-macro-language.txt | 179 
> 
>  MAINTAINERS |   2 +-
>  2 files changed, 180 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
> 
> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
> b/Documentation/kbuild/kconfig-macro-language.txt
> new file mode 100644
> index 000..1f6281b
> --- /dev/null
> +++ b/Documentation/kbuild/kconfig-macro-language.txt
> @@ -0,0 +1,179 @@
> +Concept
> +---
> +
> +The basic idea was inspired by Make. When we look at Make, we notice sort of
> +two languages in one. One language describes dependency graphs consisting of
> +targets and prerequisites. The other is a macro language for performing 
> textual
> +substitution.
> +
> +There is clear distinction between the two language stages. For example, you
> +can write a makefile like follows:
> +
> +APP := foo
> +SRC := foo.c
> +CC := gcc
> +
> +$(APP): $(SRC)
> +$(CC) -o $(APP) $(SRC)
> +
> +The macro language replaces the variable references with their expanded form,
> +and handles as if the source file were input like follows:
> +
> +foo: foo.c
> +gcc -o foo foo.c
> +
> +Then, Make analyzes the dependency graph and determines the targets to be
> +updated.
> +
> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
> +file like this:
> +
> +CC := gcc
> +
> +config CC_HAS_FOO
> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
> +
> +The macro language in Kconfig processes the source file into the following
> +intermediate:
> +
> +config CC_HAS_FOO
> +def_bool y
> +
> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
> +dependency, which is explained in kconfig-language.txt.
> +
> +
> +Variables
> +-
> +
> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
> +variable is expanded "in place" to yield a text string that may then expanded

   may then be 
expanded

> +further. To get the value of a variable, enclose the variable name in $( ).
> +As a special case, single-letter variable names can omit the parentheses and 
> is

and 
are

> +simply referenced like $X. Unlike Make, Kconfig does not support curly braces
> +as in ${CC}.
> +
> +There are two types of variables: simply expanded variables and recursively
> +expanded variables.
> +
> +A simply expanded variable is defined using the := assignment operator. Its
> +righthand side is expanded immediately upon reading the line from the Kconfig
> +file.
> +
> +A recursively expanded variable is defined using the = assignment operator.
> +Its righthand side is simply stored as the value of the variable without
> +expanding it in any way. Instead, the expansion is performed when the 
> variable
> +is used.
> +
> +There is another type of assignment operator; += is used to append text to a
> +variable. The righthand side of += is expanded immediately if the lefthand
> +side was originally defined as a simple variable. Otherwise, its evaluation 
> is
> +deferred.
> +
> +
> +Functions
> +-
> +
> +Like Make, Kconfig supports both built-in and user-defined functions. A
> +function invocation looks much like a variable reference, but includes one or
> +more parameters separated by commas:
> +
> +  $(function-name arg1, arg2, arg3)
> +
> +Some functions are implemented as a built-in function. Currently, Kconfig
> +supports the following:
> +
> + - $(shell command)
> +
> +  The 'shell' function accepts a single argument that is expanded and passed
> +  to a subshell for execution. The standard output of the command is then 
> read
> +  and returned as the value of the function. Every newline in the output is
> +  replaced with a space. Any trailing newlines are deleted. The standard 
> error
> +  is not returned, nor is any program exit status.
> +
> + - $(warning text)
> +
> +  The 'warning' function prints its arguments to stderr. The output is 
> prefixed
> +  with the name of the current Kconfig file, the current line number. It

  file and the current line number. It

> +  evaluates to an empty string.
> +
> + - $(info text)
> +
> +  The 'info' function is similar to 'warning' except that it sends its 
> argument
> +  to stdout without any Kconfig name or line number.

Are current Kconfig file name and line number available so that someone can
construct their own $(info message) messages?

> +
> +A user-defined function is defined by using the = operator. The 

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Randy Dunlap]

On 04/12/18 22:06, Masahiro Yamada wrote:
> Add a document for the macro language introduced to Kconfig.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/kbuild/kconfig-macro-language.txt | 179 
> 
>  MAINTAINERS |   2 +-
>  2 files changed, 180 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
> 
> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
> b/Documentation/kbuild/kconfig-macro-language.txt
> new file mode 100644
> index 000..1f6281b
> --- /dev/null
> +++ b/Documentation/kbuild/kconfig-macro-language.txt
> @@ -0,0 +1,179 @@
> +Concept
> +---
> +
> +The basic idea was inspired by Make. When we look at Make, we notice sort of
> +two languages in one. One language describes dependency graphs consisting of
> +targets and prerequisites. The other is a macro language for performing 
> textual
> +substitution.
> +
> +There is clear distinction between the two language stages. For example, you
> +can write a makefile like follows:
> +
> +APP := foo
> +SRC := foo.c
> +CC := gcc
> +
> +$(APP): $(SRC)
> +$(CC) -o $(APP) $(SRC)
> +
> +The macro language replaces the variable references with their expanded form,
> +and handles as if the source file were input like follows:
> +
> +foo: foo.c
> +gcc -o foo foo.c
> +
> +Then, Make analyzes the dependency graph and determines the targets to be
> +updated.
> +
> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
> +file like this:
> +
> +CC := gcc
> +
> +config CC_HAS_FOO
> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
> +
> +The macro language in Kconfig processes the source file into the following
> +intermediate:
> +
> +config CC_HAS_FOO
> +def_bool y
> +
> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
> +dependency, which is explained in kconfig-language.txt.
> +
> +
> +Variables
> +-
> +
> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
> +variable is expanded "in place" to yield a text string that may then expanded

   may then be 
expanded

> +further. To get the value of a variable, enclose the variable name in $( ).
> +As a special case, single-letter variable names can omit the parentheses and 
> is

and 
are

> +simply referenced like $X. Unlike Make, Kconfig does not support curly braces
> +as in ${CC}.
> +
> +There are two types of variables: simply expanded variables and recursively
> +expanded variables.
> +
> +A simply expanded variable is defined using the := assignment operator. Its
> +righthand side is expanded immediately upon reading the line from the Kconfig
> +file.
> +
> +A recursively expanded variable is defined using the = assignment operator.
> +Its righthand side is simply stored as the value of the variable without
> +expanding it in any way. Instead, the expansion is performed when the 
> variable
> +is used.
> +
> +There is another type of assignment operator; += is used to append text to a
> +variable. The righthand side of += is expanded immediately if the lefthand
> +side was originally defined as a simple variable. Otherwise, its evaluation 
> is
> +deferred.
> +
> +
> +Functions
> +-
> +
> +Like Make, Kconfig supports both built-in and user-defined functions. A
> +function invocation looks much like a variable reference, but includes one or
> +more parameters separated by commas:
> +
> +  $(function-name arg1, arg2, arg3)
> +
> +Some functions are implemented as a built-in function. Currently, Kconfig
> +supports the following:
> +
> + - $(shell command)
> +
> +  The 'shell' function accepts a single argument that is expanded and passed
> +  to a subshell for execution. The standard output of the command is then 
> read
> +  and returned as the value of the function. Every newline in the output is
> +  replaced with a space. Any trailing newlines are deleted. The standard 
> error
> +  is not returned, nor is any program exit status.
> +
> + - $(warning text)
> +
> +  The 'warning' function prints its arguments to stderr. The output is 
> prefixed
> +  with the name of the current Kconfig file, the current line number. It

  file and the current line number. It

> +  evaluates to an empty string.
> +
> + - $(info text)
> +
> +  The 'info' function is similar to 'warning' except that it sends its 
> argument
> +  to stdout without any Kconfig name or line number.

Are current Kconfig file name and line number available so that someone can
construct their own $(info message) messages?

> +
> +A user-defined function is defined by using the = operator. The parameters 
> are
> +referenced