[ANNOUNCE] Kconfiglib GUI menuconfig

[Ulf Magnusson]

Hello,

Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
Tkinter-based guiconfig.py in addition to the curses-based
menuconfig.py. It has been tested on Linux, Windows, and macOS.

See https://github.com/ulfalizer/Kconfiglib#menuconfig-interfaces for
a screenshot (with show-all mode on). The interface is inspired by
qconfig.

The images come from data embedded directly in guiconfig.py by
default, to avoid having to carry around a bunch of separate .gif
files.

makefile.patch now has a new 'guiconfig' target for trying out the GUI
menuconfig on the Linux kernel. Python 2 is used by default. Run 'make
PYTHONCMD=python3 guiconfig' to use Python 3.

Please tell me if you try it out and spot any issues or annoyances. :)

Cheers,
Ulf

Re: [ANN] init-kconfig - easy way to embrace Linux's kconfig

[Ulf Magnusson]

On Thu, Oct 4, 2018 at 10:03 PM Luis Chamberlain  wrote:
>
> Every now and then a project is born, and they decide to use Linux's
> kconfig to enable configuration of their project. As it stands we *know*
> kconfig is now used in at least over 12 different projects [0]. I myself
> added kconfig to one as well years ago. Even research reveals that
> kconfig has become one of the leading industrial variability modeling
> languages [1] [2].
>
> What is often difficult to do though is to start off using kconfig and
> integrating it into a project. Or updating / syncing to the latest
> kconfig from upstream Linux.
>
> I had yet another need to use kconfig for another small project so
> decided to make a clean template others can use and help keep it in sync.
> This is a passive fork which aims to keep in sync with the Linux
> kernel's latest kconfig to make it easier to keep up to date and to
> enable new projects to use and embrace kconfig on their own.  The goal
> is *not* to fork kconfig and evolve it separately, but rather keep in
> sync with the evolution of kconfig on Linux to make it easier for
> projects to use kconfig and also update their own kconfig when needed.
>
> This may also be useful if folks want to test R code on a smaller
> compartamentalized codebase.
>
> If you find this useful and you'd like to help keep it in sync, send
> patches my way as the kernel's kconfig evolves. The code is up on
> gitlab).) [3].
>
> Do we want to document this option on Linux in case folks want to try
> and embrace kconfig on their own for other projects?
>
> [0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
> [1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
> [2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
> [3] https://gitlab.com/mcgrof/init-kconfig
>
>   Luis

Shameless self-plug:

There's also a Python Kconfig implementation that's starting to get
picked up by several projects: https://github.com/ulfalizer/kconfiglib

It has a terminal menuconfig interface with a lot more features than
mconf (a demonstration is available at
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/menuconfig.gif),
and can also be used e.g. to generate cross-referenced Kconfig
documentation that includes propagated dependencies:
https://docs.zephyrproject.org/latest/reference/kconfig/index.html
(note: heavy page).

Kconfiglib is based around a library (an old version appears in e.g.
U-Boot and Yocto, and a newer version in e.g. Espressif). The
documentation generation is just a script
(https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/scripts/genrest.py),
and the same goes for the menuconfig and the other tools. The core
library takes part of all the trickiness related to evaluating
symbols.

I realize there would probably be massive opposition to adding a
Python dependency to a core part of the kernel, so I'm not going for
that. For most other projects, I think it's a good fit though.

Cheers,
Ulf

Re: [ANN] init-kconfig - easy way to embrace Linux's kconfig

[Ulf Magnusson]

On Thu, Oct 4, 2018 at 10:03 PM Luis Chamberlain  wrote:
>
> Every now and then a project is born, and they decide to use Linux's
> kconfig to enable configuration of their project. As it stands we *know*
> kconfig is now used in at least over 12 different projects [0]. I myself
> added kconfig to one as well years ago. Even research reveals that
> kconfig has become one of the leading industrial variability modeling
> languages [1] [2].
>
> What is often difficult to do though is to start off using kconfig and
> integrating it into a project. Or updating / syncing to the latest
> kconfig from upstream Linux.
>
> I had yet another need to use kconfig for another small project so
> decided to make a clean template others can use and help keep it in sync.
> This is a passive fork which aims to keep in sync with the Linux
> kernel's latest kconfig to make it easier to keep up to date and to
> enable new projects to use and embrace kconfig on their own.  The goal
> is *not* to fork kconfig and evolve it separately, but rather keep in
> sync with the evolution of kconfig on Linux to make it easier for
> projects to use kconfig and also update their own kconfig when needed.
>
> This may also be useful if folks want to test R code on a smaller
> compartamentalized codebase.
>
> If you find this useful and you'd like to help keep it in sync, send
> patches my way as the kernel's kconfig evolves. The code is up on
> gitlab).) [3].
>
> Do we want to document this option on Linux in case folks want to try
> and embrace kconfig on their own for other projects?
>
> [0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
> [1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
> [2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
> [3] https://gitlab.com/mcgrof/init-kconfig
>
>   Luis

Shameless self-plug:

There's also a Python Kconfig implementation that's starting to get
picked up by several projects: https://github.com/ulfalizer/kconfiglib

It has a terminal menuconfig interface with a lot more features than
mconf (a demonstration is available at
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/menuconfig.gif),
and can also be used e.g. to generate cross-referenced Kconfig
documentation that includes propagated dependencies:
https://docs.zephyrproject.org/latest/reference/kconfig/index.html
(note: heavy page).

Kconfiglib is based around a library (an old version appears in e.g.
U-Boot and Yocto, and a newer version in e.g. Espressif). The
documentation generation is just a script
(https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/scripts/genrest.py),
and the same goes for the menuconfig and the other tools. The core
library takes part of all the trickiness related to evaluating
symbols.

I realize there would probably be massive opposition to adding a
Python dependency to a core part of the kernel, so I'm not going for
that. For most other projects, I think it's a good fit though.

Cheers,
Ulf

[ANNOUNCE] Kconfiglib menuconfig and documentation generation updates

[Ulf Magnusson]

Hello,

Here's two small Kconfiglib (https://github.com/ulfalizer/kconfiglib) updates.

First, I've made it a lot easier to try out the menuconfig implementation on
the kernel. This will work now, in the kernel root:

  $ git clone https://github.com/ulfalizer/Kconfiglib.git
  $ git am Kconfiglib/makefile.patch
  $ make kmenuconfig

Here's an animation that demonstrates various menuconfig features:
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/menuconfig.gif

Secondly, there's now a handy cross-referenced documentation generation script
available.

Example documentation output (warning: heavy page, lots of symbols):
https://docs.zephyrproject.org/latest/reference/kconfig/index.html

The script that generates the documentation:
https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/scripts/genrest.py

The recently added Kconfig preprocessor has been implemented for a while now,
along with an extension that allows preprocessor functions to be defined in
Python.

I've also fixed some broken/incomplete behavior from the C tools, like not
being able to add symbols to choices by giving them a name and defining them in
multiple locations (though I think projects sometimes overdo multiple
definitions :). This is actually just a menuconfig hack that aggregates the
menu nodes from all choice definition locations when you enter a choice.

Zephyr and several smaller projects now use Kconfiglib exclusively.

Feedback appreciated!

Cheers,
Ulf

[ANNOUNCE] Kconfiglib menuconfig and documentation generation updates

[Ulf Magnusson]

Hello,

Here's two small Kconfiglib (https://github.com/ulfalizer/kconfiglib) updates.

First, I've made it a lot easier to try out the menuconfig implementation on
the kernel. This will work now, in the kernel root:

  $ git clone https://github.com/ulfalizer/Kconfiglib.git
  $ git am Kconfiglib/makefile.patch
  $ make kmenuconfig

Here's an animation that demonstrates various menuconfig features:
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/menuconfig.gif

Secondly, there's now a handy cross-referenced documentation generation script
available.

Example documentation output (warning: heavy page, lots of symbols):
https://docs.zephyrproject.org/latest/reference/kconfig/index.html

The script that generates the documentation:
https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/scripts/genrest.py

The recently added Kconfig preprocessor has been implemented for a while now,
along with an extension that allows preprocessor functions to be defined in
Python.

I've also fixed some broken/incomplete behavior from the C tools, like not
being able to add symbols to choices by giving them a name and defining them in
multiple locations (though I think projects sometimes overdo multiple
definitions :). This is actually just a menuconfig hack that aggregates the
menu nodes from all choice definition locations when you enter a choice.

Zephyr and several smaller projects now use Kconfiglib exclusively.

Feedback appreciated!

Cheers,
Ulf

Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='

[Ulf Magnusson]

On Thu, May 24, 2018 at 6:45 AM, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> 2018-05-21 20:06 GMT+09:00 Ulf Magnusson <ulfali...@gmail.com>:
>
>>>
>>> static char *__expand_string(const char **str, bool (*is_end)(const char *))
>>> {
>>> const char *in, *prev_in, *p;
>>> char *new, *out;
>>> size_t outlen;
>>>
>>> out = xmalloc(1);
>>> *out = 0;
>>>
>>> p = in = *str;
>>>
>>> while (1) {
>>> if (*p == '$') {
>>> prev_in = in;
>>> in = p + 1;
>>> new = expand_dollar();
>>> outlen = strlen(out) + (p - prev_in) + strlen(new) 
>>> + 1;
>>> out = xrealloc(out, outlen);
>>> strncat(out, prev_in, p - prev_in);
>>> strcat(out, new);
>>> free(new);
>>> p = in;
>>> continue;
>>> }
>>>
>>> if (is_end(p))
>>> break;
>>>
>>> p++;
>>> }
>>>
>>> outlen = strlen(out) + (p - in) + 1;
>>> out = xrealloc(out, outlen);
>>> strncat(out, in, p - in);
>>>
>>> *str = p;
>>>
>>> return out;
>>> }
>>>
>>> static bool is_end_of_str(const char *s)
>>> {
>>> return !*s;
>>> }
>>>
>>> char *expand_string(const char *in)
>>> {
>>> return __expand_string(, is_end_of_str);
>>> }
>>>
>>> static bool is_end_of_token(const char *s)
>>> {
>>> return !(isalnum(*s) || *s == '_' || *s == '-' || *s == '.' ||
>>> *s == '/');
>>> }
>>>
>>> char *expand_one_token(const char **str)
>>> {
>>> return __expand_string(str, is_end_of_token);
>>> }
>>
>> Yep, something like that would be nicer I think.
>>
>> This variant might work too (untested):
>>
>>   dollar_i = p;
>>   p++;
>>   expansion = expand_dollar();
>>
>>   out = xrealloc(out, strlen(out) + (dollar_i - in)
>>   + strlen(expansion) + 1);
>>   strncat(out, in, dollar_i - in);
>>   strcat(out, expansion);
>>   free(expansion);
>>
>>   in = p;
>>
>>   continue;
>>
>> The p++ would disappear if expand_dollar() took a pointer to the '$'.
>>
>
>
> I took the variable name "expansion" because
> it is more descriptive than "new".
>
>
> I rewrote like follows:
>
>
> static char *__expand_string(const char **str, bool (*is_end)(const char *))
> {
> const char *in, *p;
> char *expansion, *out;
> size_t in_len, out_len;
>
> out = xmalloc(1);
> *out = 0;
> out_len = 1;
>
> p = in = *str;
>
> while (1) {
> if (*p == '$') {
> in_len = p - in;
> p++;
> expansion = expand_dollar();
> out_len += in_len + strlen(expansion);
> out = xrealloc(out, out_len);
> strncat(out, in, in_len);
> strcat(out, expansion);
> free(expansion);
> in = p;
> continue;
> }
>
> if (is_end(p))
> break;
>
> p++;
> }
>
> in_len = p - in;
> out_len += in_len;
> out = xrealloc(out, out_len);
> strncat(out, in, in_len);
>
> /* Advance 'str' to the end character */
> *str = p;
>
> return out;
> }
>
>
>
> I used "out_len" to remember the length of "out"
> instead of calculating strlen(out) every time.
>
> I do not need dollar_p.
>
>
>
>
> --
> Best Regards
> Masahiro Yamada

Looks good to me.

Could keep some 'out' pointer to avoid the str(n)cat()s too, but
pretty sure it's overkilling it. Should have some general string
buffer helpers at that point I think. :)

Cheers,
Ulf

Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='

[Ulf Magnusson]

On Thu, May 24, 2018 at 6:45 AM, Masahiro Yamada
 wrote:
> 2018-05-21 20:06 GMT+09:00 Ulf Magnusson :
>
>>>
>>> static char *__expand_string(const char **str, bool (*is_end)(const char *))
>>> {
>>> const char *in, *prev_in, *p;
>>> char *new, *out;
>>> size_t outlen;
>>>
>>> out = xmalloc(1);
>>> *out = 0;
>>>
>>> p = in = *str;
>>>
>>> while (1) {
>>> if (*p == '$') {
>>> prev_in = in;
>>> in = p + 1;
>>> new = expand_dollar();
>>> outlen = strlen(out) + (p - prev_in) + strlen(new) 
>>> + 1;
>>> out = xrealloc(out, outlen);
>>> strncat(out, prev_in, p - prev_in);
>>> strcat(out, new);
>>> free(new);
>>> p = in;
>>> continue;
>>> }
>>>
>>> if (is_end(p))
>>> break;
>>>
>>> p++;
>>> }
>>>
>>> outlen = strlen(out) + (p - in) + 1;
>>> out = xrealloc(out, outlen);
>>> strncat(out, in, p - in);
>>>
>>> *str = p;
>>>
>>> return out;
>>> }
>>>
>>> static bool is_end_of_str(const char *s)
>>> {
>>> return !*s;
>>> }
>>>
>>> char *expand_string(const char *in)
>>> {
>>> return __expand_string(, is_end_of_str);
>>> }
>>>
>>> static bool is_end_of_token(const char *s)
>>> {
>>> return !(isalnum(*s) || *s == '_' || *s == '-' || *s == '.' ||
>>> *s == '/');
>>> }
>>>
>>> char *expand_one_token(const char **str)
>>> {
>>> return __expand_string(str, is_end_of_token);
>>> }
>>
>> Yep, something like that would be nicer I think.
>>
>> This variant might work too (untested):
>>
>>   dollar_i = p;
>>   p++;
>>   expansion = expand_dollar();
>>
>>   out = xrealloc(out, strlen(out) + (dollar_i - in)
>>   + strlen(expansion) + 1);
>>   strncat(out, in, dollar_i - in);
>>   strcat(out, expansion);
>>   free(expansion);
>>
>>   in = p;
>>
>>   continue;
>>
>> The p++ would disappear if expand_dollar() took a pointer to the '$'.
>>
>
>
> I took the variable name "expansion" because
> it is more descriptive than "new".
>
>
> I rewrote like follows:
>
>
> static char *__expand_string(const char **str, bool (*is_end)(const char *))
> {
> const char *in, *p;
> char *expansion, *out;
> size_t in_len, out_len;
>
> out = xmalloc(1);
> *out = 0;
> out_len = 1;
>
> p = in = *str;
>
> while (1) {
> if (*p == '$') {
> in_len = p - in;
> p++;
> expansion = expand_dollar();
> out_len += in_len + strlen(expansion);
> out = xrealloc(out, out_len);
> strncat(out, in, in_len);
> strcat(out, expansion);
> free(expansion);
> in = p;
> continue;
> }
>
> if (is_end(p))
> break;
>
> p++;
> }
>
> in_len = p - in;
> out_len += in_len;
> out = xrealloc(out, out_len);
> strncat(out, in, in_len);
>
> /* Advance 'str' to the end character */
> *str = p;
>
> return out;
> }
>
>
>
> I used "out_len" to remember the length of "out"
> instead of calculating strlen(out) every time.
>
> I do not need dollar_p.
>
>
>
>
> --
> Best Regards
> Masahiro Yamada

Looks good to me.

Could keep some 'out' pointer to avoid the str(n)cat()s too, but
pretty sure it's overkilling it. Should have some general string
buffer helpers at that point I think. :)

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Mon, May 21, 2018 at 5:47 AM, Randy Dunlap <rdun...@infradead.org> wrote:
> On 05/20/2018 08:33 PM, Ulf Magnusson wrote:
>> On Mon, May 21, 2018 at 4:45 AM, Randy Dunlap <rdun...@infradead.org> wrote:
>>> On 05/19/2018 09:47 PM, Ulf Magnusson wrote:
>>>> On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap <rdun...@infradead.org> 
>>>> wrote:
>>>>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>>>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've added incremental search for jumping directly to a symbol now.
>>>>>>> Regular expressions are supported as well.
>>>>>>>
>>>>>>> Some screenshots below:
>>>>>>>
>>>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>>>>>
>>>>>>> The last screenshot shows how things might look after you jump to a
>>>>>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>>>>>> mode was turned on automatically.
>>>>>>
>>>>>> Hi Ulf,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have 
>>>>>> the UI now.
>>>>>>
>>>>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>>>>> Kconfiglib/menuconfig.py
>>>>>>
>>>>>> so yes, a real Makefile target would be nice. :)
>>>>>
>>>>> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
>>>>> _DEBUGFS).  Using:
>>>>>
>>>>> /.*_DEBUG$
>>>>>
>>>>> shows me 6 symbols:
>>>>> ATH9K_COMMON_DEBUG
>>>>> DVB_B2C2_FLEXCOP_DEBUG
>>>>> HAVE_DMA_API_DEBUG
>>>>> IP_DCCP_TFRC_DEBUG
>>>>> NFS_DEBUG
>>>>> PM_SLEEP_DEBUG
>>>>>
>>>>> so where are the other (approx.) 176?
>>>>> see:
>>>>> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig 
>>>>> | wc
>>>>> 182 3649179
>>>>>
>>>>>
>>>>> Anyway, something for you to look at. :)
>>>>>
>>>>> --
>>>>> ~Randy
>>>>
>>>> It's related to how the search is done. Searching for "DEBUG\b" (word
>>>> boundary) instead will find all of them.
>>>>
>>>> A string is generated for each symbol. For symbols with prompts, this
>>>> string includes the prompt as well, so you get e.g.
>>>>
>>>> AB8500_DEBUG "Enable debug info via debugfs"
>>>>
>>>> Those strings are then searched/displayed.
>>>>
>>>> What you got with your search was all symbols whose names end in
>>>> "_DEBUG" that don't have a prompt.
>>>>
>>>> The nice thing about searching both the name and the prompt is that
>>>> e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
>>>> add menus to the search, by generating 'menu: "menu title"' strings
>>>> for them.
>>>>
>>>> It's a bit awkward/unintuitive that what you tried doesn't work
>>>> though. Maybe the symbol name could be searched separately from the
>>>> prompt, though I'd be a bit sad to abandon the super simple
>>>> single-string-per-entry implementation approach. :)
>>>
>>> Hi Ulf,
>>>
>>> What else are you planning to do with /(search)?
>>
>> Here's the stuff I've thought of so far:
>>
>>   - Display invisible symbols in red (to match show-all mode)
>>
>>   - Search prompts of menus and comments as well
>>
>>   - Have [F1] show the help display without canceling the search,
>> so you can quickly scan through a bunch of symbols
>>
>> Maybe you could get fancy with stuff like finding symbols that are
>> related to other symbols in particular ways too...
>>
>>> /syscall lists 20 or so symbols. It would be nice if each one of those
>>> showed its current setting [y,n,maybe^Wm].
>>
>> Nice idea. I added it:
>> https://github.com/ulfalizer/Kconfiglib/commit/3161affaa5bb8350a39bfd305c56171a25b02151
>>
>> Works for strings/int/hex too.
>
> Thanks.
>
>>> I like Toggle show-all mode.  When I use xconfig, I usually turn on most
>>> of its options, including one like that.
>>
>> IIRC, xconfig doesn't make it very clear which symbols are invisible
>> in show-all mode. That's why I made them red.
>
> Yes, that's helpful.
>
>
> --
> ~Randy

Hello,

I've added a mode that lists the names of all symbols in the menu now
as well, toggled with 'c' ('n' was taken :).

Any other features you miss from xconfig? Other suggestions?

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Mon, May 21, 2018 at 5:47 AM, Randy Dunlap  wrote:
> On 05/20/2018 08:33 PM, Ulf Magnusson wrote:
>> On Mon, May 21, 2018 at 4:45 AM, Randy Dunlap  wrote:
>>> On 05/19/2018 09:47 PM, Ulf Magnusson wrote:
>>>> On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap  
>>>> wrote:
>>>>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>>>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've added incremental search for jumping directly to a symbol now.
>>>>>>> Regular expressions are supported as well.
>>>>>>>
>>>>>>> Some screenshots below:
>>>>>>>
>>>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>>>>>
>>>>>>> The last screenshot shows how things might look after you jump to a
>>>>>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>>>>>> mode was turned on automatically.
>>>>>>
>>>>>> Hi Ulf,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have 
>>>>>> the UI now.
>>>>>>
>>>>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>>>>> Kconfiglib/menuconfig.py
>>>>>>
>>>>>> so yes, a real Makefile target would be nice. :)
>>>>>
>>>>> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
>>>>> _DEBUGFS).  Using:
>>>>>
>>>>> /.*_DEBUG$
>>>>>
>>>>> shows me 6 symbols:
>>>>> ATH9K_COMMON_DEBUG
>>>>> DVB_B2C2_FLEXCOP_DEBUG
>>>>> HAVE_DMA_API_DEBUG
>>>>> IP_DCCP_TFRC_DEBUG
>>>>> NFS_DEBUG
>>>>> PM_SLEEP_DEBUG
>>>>>
>>>>> so where are the other (approx.) 176?
>>>>> see:
>>>>> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig 
>>>>> | wc
>>>>> 182 3649179
>>>>>
>>>>>
>>>>> Anyway, something for you to look at. :)
>>>>>
>>>>> --
>>>>> ~Randy
>>>>
>>>> It's related to how the search is done. Searching for "DEBUG\b" (word
>>>> boundary) instead will find all of them.
>>>>
>>>> A string is generated for each symbol. For symbols with prompts, this
>>>> string includes the prompt as well, so you get e.g.
>>>>
>>>> AB8500_DEBUG "Enable debug info via debugfs"
>>>>
>>>> Those strings are then searched/displayed.
>>>>
>>>> What you got with your search was all symbols whose names end in
>>>> "_DEBUG" that don't have a prompt.
>>>>
>>>> The nice thing about searching both the name and the prompt is that
>>>> e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
>>>> add menus to the search, by generating 'menu: "menu title"' strings
>>>> for them.
>>>>
>>>> It's a bit awkward/unintuitive that what you tried doesn't work
>>>> though. Maybe the symbol name could be searched separately from the
>>>> prompt, though I'd be a bit sad to abandon the super simple
>>>> single-string-per-entry implementation approach. :)
>>>
>>> Hi Ulf,
>>>
>>> What else are you planning to do with /(search)?
>>
>> Here's the stuff I've thought of so far:
>>
>>   - Display invisible symbols in red (to match show-all mode)
>>
>>   - Search prompts of menus and comments as well
>>
>>   - Have [F1] show the help display without canceling the search,
>> so you can quickly scan through a bunch of symbols
>>
>> Maybe you could get fancy with stuff like finding symbols that are
>> related to other symbols in particular ways too...
>>
>>> /syscall lists 20 or so symbols. It would be nice if each one of those
>>> showed its current setting [y,n,maybe^Wm].
>>
>> Nice idea. I added it:
>> https://github.com/ulfalizer/Kconfiglib/commit/3161affaa5bb8350a39bfd305c56171a25b02151
>>
>> Works for strings/int/hex too.
>
> Thanks.
>
>>> I like Toggle show-all mode.  When I use xconfig, I usually turn on most
>>> of its options, including one like that.
>>
>> IIRC, xconfig doesn't make it very clear which symbols are invisible
>> in show-all mode. That's why I made them red.
>
> Yes, that's helpful.
>
>
> --
> ~Randy

Hello,

I've added a mode that lists the names of all symbols in the menu now
as well, toggled with 'c' ('n' was taken :).

Any other features you miss from xconfig? Other suggestions?

Cheers,
Ulf

Re: [PATCH v4 07/31] kconfig: add built-in function support

[Ulf Magnusson]

On Tue, May 22, 2018 at 6:50 AM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Tue, May 22, 2018 at 5:11 AM, Masahiro Yamada
> <yamada.masah...@socionext.com> wrote:
>> 2018-05-22 0:10 GMT+09:00 Ulf Magnusson <ulfali...@gmail.com>:
>>> On Mon, May 21, 2018 at 4:32 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
>>>> On Mon, May 21, 2018 at 4:23 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
>>>>> On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborg <s...@ravnborg.org> wrote:
>>>>>> Will the following be equal:
>>>>>>
>>>>>> $(foo,abc,$(x),$(y))
>>>>>> $(foo, abc, $(x), $(y))
>>>>>>
>>>>>> make is rather annoying as space is significant, but there seems no good 
>>>>>> reason
>>>>>> for kconfig to inheritate this.
>>>>>> So unless there are good arguments consider alloing the spaces.
>>>>>> If the current implmentation already supports optional spaces then I 
>>>>>> just missed
>>>>>> it whie reviewing.
>>>>>>
>>>>>> Sam
>>>>>
>>>>> +1 from me.
>>>>>
>>>>> I also find the rules for whitespace in Make confusing, and always
>>>>> have to look them up when doing trickier stuff. Maybe they're the
>>>>> result of people not considering whitespace initially, and stuff
>>>>> getting tacked on later. GNU Make adds some alternate syntaxes with
>>>>> quotes.
>>>>>
>>>>> I was going to mention shell, but it looks like you already did. :)
>>>>>
>>>>> If we go with Make-like syntax, maybe we could at least have a variant
>>>>> with fewer whitespace gotchas.
>>>>>
>>>>> Cheers,
>>>>> Ulf
>>>>
>>>> Maybe it'd be a pain to implement, but something like $(foo $(x) "two
>>>> words" "interpolated $(stuff)") seems pretty nice, with three
>>>> arguments there.
>>>
>>> Guess that might interact poorly with $(shell foo "bar baz") though.
>>> Kinda nice to have a syntax that doesn't overlap with shell when
>>> building shell commands.
>>
>>
>> Right.  I can easily imagine
>> that would end up with more gotchas due to quoting and escaping.
>
> Yeah, you're right. It's probably trying to fix something that isn't
> broken. Make's syntax really isn't bad there, just slightly
> non-obvious at first...
>
> Think it's fine now. Better to commit to the syntax than trying to be
> "helpful" by adding a bunch of random exceptions too. That probably
> gives a bigger mess in the end...
>
> Cheers,
> Ulf

I'm fine with the comma-after-function-name change though. That just
makes it more consistent.

Cheers,
Ulf

Re: [PATCH v4 07/31] kconfig: add built-in function support

[Ulf Magnusson]

On Tue, May 22, 2018 at 6:50 AM, Ulf Magnusson  wrote:
> On Tue, May 22, 2018 at 5:11 AM, Masahiro Yamada
>  wrote:
>> 2018-05-22 0:10 GMT+09:00 Ulf Magnusson :
>>> On Mon, May 21, 2018 at 4:32 PM, Ulf Magnusson  wrote:
>>>> On Mon, May 21, 2018 at 4:23 PM, Ulf Magnusson  wrote:
>>>>> On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborg  wrote:
>>>>>> Will the following be equal:
>>>>>>
>>>>>> $(foo,abc,$(x),$(y))
>>>>>> $(foo, abc, $(x), $(y))
>>>>>>
>>>>>> make is rather annoying as space is significant, but there seems no good 
>>>>>> reason
>>>>>> for kconfig to inheritate this.
>>>>>> So unless there are good arguments consider alloing the spaces.
>>>>>> If the current implmentation already supports optional spaces then I 
>>>>>> just missed
>>>>>> it whie reviewing.
>>>>>>
>>>>>> Sam
>>>>>
>>>>> +1 from me.
>>>>>
>>>>> I also find the rules for whitespace in Make confusing, and always
>>>>> have to look them up when doing trickier stuff. Maybe they're the
>>>>> result of people not considering whitespace initially, and stuff
>>>>> getting tacked on later. GNU Make adds some alternate syntaxes with
>>>>> quotes.
>>>>>
>>>>> I was going to mention shell, but it looks like you already did. :)
>>>>>
>>>>> If we go with Make-like syntax, maybe we could at least have a variant
>>>>> with fewer whitespace gotchas.
>>>>>
>>>>> Cheers,
>>>>> Ulf
>>>>
>>>> Maybe it'd be a pain to implement, but something like $(foo $(x) "two
>>>> words" "interpolated $(stuff)") seems pretty nice, with three
>>>> arguments there.
>>>
>>> Guess that might interact poorly with $(shell foo "bar baz") though.
>>> Kinda nice to have a syntax that doesn't overlap with shell when
>>> building shell commands.
>>
>>
>> Right.  I can easily imagine
>> that would end up with more gotchas due to quoting and escaping.
>
> Yeah, you're right. It's probably trying to fix something that isn't
> broken. Make's syntax really isn't bad there, just slightly
> non-obvious at first...
>
> Think it's fine now. Better to commit to the syntax than trying to be
> "helpful" by adding a bunch of random exceptions too. That probably
> gives a bigger mess in the end...
>
> Cheers,
> Ulf

I'm fine with the comma-after-function-name change though. That just
makes it more consistent.

Cheers,
Ulf

Re: [PATCH v4 07/31] kconfig: add built-in function support

[Ulf Magnusson]

On Tue, May 22, 2018 at 5:11 AM, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> 2018-05-22 0:10 GMT+09:00 Ulf Magnusson <ulfali...@gmail.com>:
>> On Mon, May 21, 2018 at 4:32 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
>>> On Mon, May 21, 2018 at 4:23 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
>>>> On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborg <s...@ravnborg.org> wrote:
>>>>> Will the following be equal:
>>>>>
>>>>> $(foo,abc,$(x),$(y))
>>>>> $(foo, abc, $(x), $(y))
>>>>>
>>>>> make is rather annoying as space is significant, but there seems no good 
>>>>> reason
>>>>> for kconfig to inheritate this.
>>>>> So unless there are good arguments consider alloing the spaces.
>>>>> If the current implmentation already supports optional spaces then I just 
>>>>> missed
>>>>> it whie reviewing.
>>>>>
>>>>> Sam
>>>>
>>>> +1 from me.
>>>>
>>>> I also find the rules for whitespace in Make confusing, and always
>>>> have to look them up when doing trickier stuff. Maybe they're the
>>>> result of people not considering whitespace initially, and stuff
>>>> getting tacked on later. GNU Make adds some alternate syntaxes with
>>>> quotes.
>>>>
>>>> I was going to mention shell, but it looks like you already did. :)
>>>>
>>>> If we go with Make-like syntax, maybe we could at least have a variant
>>>> with fewer whitespace gotchas.
>>>>
>>>> Cheers,
>>>> Ulf
>>>
>>> Maybe it'd be a pain to implement, but something like $(foo $(x) "two
>>> words" "interpolated $(stuff)") seems pretty nice, with three
>>> arguments there.
>>
>> Guess that might interact poorly with $(shell foo "bar baz") though.
>> Kinda nice to have a syntax that doesn't overlap with shell when
>> building shell commands.
>
>
> Right.  I can easily imagine
> that would end up with more gotchas due to quoting and escaping.

Yeah, you're right. It's probably trying to fix something that isn't
broken. Make's syntax really isn't bad there, just slightly
non-obvious at first...

Think it's fine now. Better to commit to the syntax than trying to be
"helpful" by adding a bunch of random exceptions too. That probably
gives a bigger mess in the end...

Cheers,
Ulf

Re: [PATCH v4 07/31] kconfig: add built-in function support

[Ulf Magnusson]

On Tue, May 22, 2018 at 5:11 AM, Masahiro Yamada
 wrote:
> 2018-05-22 0:10 GMT+09:00 Ulf Magnusson :
>> On Mon, May 21, 2018 at 4:32 PM, Ulf Magnusson  wrote:
>>> On Mon, May 21, 2018 at 4:23 PM, Ulf Magnusson  wrote:
>>>> On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborg  wrote:
>>>>> Will the following be equal:
>>>>>
>>>>> $(foo,abc,$(x),$(y))
>>>>> $(foo, abc, $(x), $(y))
>>>>>
>>>>> make is rather annoying as space is significant, but there seems no good 
>>>>> reason
>>>>> for kconfig to inheritate this.
>>>>> So unless there are good arguments consider alloing the spaces.
>>>>> If the current implmentation already supports optional spaces then I just 
>>>>> missed
>>>>> it whie reviewing.
>>>>>
>>>>> Sam
>>>>
>>>> +1 from me.
>>>>
>>>> I also find the rules for whitespace in Make confusing, and always
>>>> have to look them up when doing trickier stuff. Maybe they're the
>>>> result of people not considering whitespace initially, and stuff
>>>> getting tacked on later. GNU Make adds some alternate syntaxes with
>>>> quotes.
>>>>
>>>> I was going to mention shell, but it looks like you already did. :)
>>>>
>>>> If we go with Make-like syntax, maybe we could at least have a variant
>>>> with fewer whitespace gotchas.
>>>>
>>>> Cheers,
>>>> Ulf
>>>
>>> Maybe it'd be a pain to implement, but something like $(foo $(x) "two
>>> words" "interpolated $(stuff)") seems pretty nice, with three
>>> arguments there.
>>
>> Guess that might interact poorly with $(shell foo "bar baz") though.
>> Kinda nice to have a syntax that doesn't overlap with shell when
>> building shell commands.
>
>
> Right.  I can easily imagine
> that would end up with more gotchas due to quoting and escaping.

Yeah, you're right. It's probably trying to fix something that isn't
broken. Make's syntax really isn't bad there, just slightly
non-obvious at first...

Think it's fine now. Better to commit to the syntax than trying to be
"helpful" by adding a bunch of random exceptions too. That probably
gives a bigger mess in the end...

Cheers,
Ulf

Re: [PATCH v4 07/31] kconfig: add built-in function support

[Ulf Magnusson]

On Mon, May 21, 2018 at 4:32 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Mon, May 21, 2018 at 4:23 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
>> On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborg <s...@ravnborg.org> wrote:
>>> Will the following be equal:
>>>
>>> $(foo,abc,$(x),$(y))
>>> $(foo, abc, $(x), $(y))
>>>
>>> make is rather annoying as space is significant, but there seems no good 
>>> reason
>>> for kconfig to inheritate this.
>>> So unless there are good arguments consider alloing the spaces.
>>> If the current implmentation already supports optional spaces then I just 
>>> missed
>>> it whie reviewing.
>>>
>>> Sam
>>
>> +1 from me.
>>
>> I also find the rules for whitespace in Make confusing, and always
>> have to look them up when doing trickier stuff. Maybe they're the
>> result of people not considering whitespace initially, and stuff
>> getting tacked on later. GNU Make adds some alternate syntaxes with
>> quotes.
>>
>> I was going to mention shell, but it looks like you already did. :)
>>
>> If we go with Make-like syntax, maybe we could at least have a variant
>> with fewer whitespace gotchas.
>>
>> Cheers,
>> Ulf
>
> Maybe it'd be a pain to implement, but something like $(foo $(x) "two
> words" "interpolated $(stuff)") seems pretty nice, with three
> arguments there.

Guess that might interact poorly with $(shell foo "bar baz") though.
Kinda nice to have a syntax that doesn't overlap with shell when
building shell commands.

Still wondering if you could get rid of some of the Make gotchas
without losing other stuff...

Cheers,
Ulf

Re: [PATCH v4 07/31] kconfig: add built-in function support

[Ulf Magnusson]

On Mon, May 21, 2018 at 4:32 PM, Ulf Magnusson  wrote:
> On Mon, May 21, 2018 at 4:23 PM, Ulf Magnusson  wrote:
>> On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborg  wrote:
>>> Will the following be equal:
>>>
>>> $(foo,abc,$(x),$(y))
>>> $(foo, abc, $(x), $(y))
>>>
>>> make is rather annoying as space is significant, but there seems no good 
>>> reason
>>> for kconfig to inheritate this.
>>> So unless there are good arguments consider alloing the spaces.
>>> If the current implmentation already supports optional spaces then I just 
>>> missed
>>> it whie reviewing.
>>>
>>> Sam
>>
>> +1 from me.
>>
>> I also find the rules for whitespace in Make confusing, and always
>> have to look them up when doing trickier stuff. Maybe they're the
>> result of people not considering whitespace initially, and stuff
>> getting tacked on later. GNU Make adds some alternate syntaxes with
>> quotes.
>>
>> I was going to mention shell, but it looks like you already did. :)
>>
>> If we go with Make-like syntax, maybe we could at least have a variant
>> with fewer whitespace gotchas.
>>
>> Cheers,
>> Ulf
>
> Maybe it'd be a pain to implement, but something like $(foo $(x) "two
> words" "interpolated $(stuff)") seems pretty nice, with three
> arguments there.

Guess that might interact poorly with $(shell foo "bar baz") though.
Kinda nice to have a syntax that doesn't overlap with shell when
building shell commands.

Still wondering if you could get rid of some of the Make gotchas
without losing other stuff...

Cheers,
Ulf

Re: [PATCH v4 07/31] kconfig: add built-in function support

[Ulf Magnusson]

On Mon, May 21, 2018 at 4:23 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborg <s...@ravnborg.org> wrote:
>> Will the following be equal:
>>
>> $(foo,abc,$(x),$(y))
>> $(foo, abc, $(x), $(y))
>>
>> make is rather annoying as space is significant, but there seems no good 
>> reason
>> for kconfig to inheritate this.
>> So unless there are good arguments consider alloing the spaces.
>> If the current implmentation already supports optional spaces then I just 
>> missed
>> it whie reviewing.
>>
>> Sam
>
> +1 from me.
>
> I also find the rules for whitespace in Make confusing, and always
> have to look them up when doing trickier stuff. Maybe they're the
> result of people not considering whitespace initially, and stuff
> getting tacked on later. GNU Make adds some alternate syntaxes with
> quotes.
>
> I was going to mention shell, but it looks like you already did. :)
>
> If we go with Make-like syntax, maybe we could at least have a variant
> with fewer whitespace gotchas.
>
> Cheers,
> Ulf

Maybe it'd be a pain to implement, but something like $(foo $(x) "two
words" "interpolated $(stuff)") seems pretty nice, with three
arguments there.

For variables too:

  x = foo
  y = "two words"

Or have mandatory quotes, but yeah, bit spammy there maybe.

Cheers,
Ulf

Re: [PATCH v4 07/31] kconfig: add built-in function support

[Ulf Magnusson]

On Mon, May 21, 2018 at 4:23 PM, Ulf Magnusson  wrote:
> On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborg  wrote:
>> Will the following be equal:
>>
>> $(foo,abc,$(x),$(y))
>> $(foo, abc, $(x), $(y))
>>
>> make is rather annoying as space is significant, but there seems no good 
>> reason
>> for kconfig to inheritate this.
>> So unless there are good arguments consider alloing the spaces.
>> If the current implmentation already supports optional spaces then I just 
>> missed
>> it whie reviewing.
>>
>> Sam
>
> +1 from me.
>
> I also find the rules for whitespace in Make confusing, and always
> have to look them up when doing trickier stuff. Maybe they're the
> result of people not considering whitespace initially, and stuff
> getting tacked on later. GNU Make adds some alternate syntaxes with
> quotes.
>
> I was going to mention shell, but it looks like you already did. :)
>
> If we go with Make-like syntax, maybe we could at least have a variant
> with fewer whitespace gotchas.
>
> Cheers,
> Ulf

Maybe it'd be a pain to implement, but something like $(foo $(x) "two
words" "interpolated $(stuff)") seems pretty nice, with three
arguments there.

For variables too:

  x = foo
  y = "two words"

Or have mandatory quotes, but yeah, bit spammy there maybe.

Cheers,
Ulf

Re: [PATCH v4 07/31] kconfig: add built-in function support

[Ulf Magnusson]

On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborg  wrote:
> Will the following be equal:
>
> $(foo,abc,$(x),$(y))
> $(foo, abc, $(x), $(y))
>
> make is rather annoying as space is significant, but there seems no good 
> reason
> for kconfig to inheritate this.
> So unless there are good arguments consider alloing the spaces.
> If the current implmentation already supports optional spaces then I just 
> missed
> it whie reviewing.
>
> Sam

+1 from me.

I also find the rules for whitespace in Make confusing, and always
have to look them up when doing trickier stuff. Maybe they're the
result of people not considering whitespace initially, and stuff
getting tacked on later. GNU Make adds some alternate syntaxes with
quotes.

I was going to mention shell, but it looks like you already did. :)

If we go with Make-like syntax, maybe we could at least have a variant
with fewer whitespace gotchas.

Cheers,
Ulf

Re: [PATCH v4 07/31] kconfig: add built-in function support

[Ulf Magnusson]

On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborg  wrote:
> Will the following be equal:
>
> $(foo,abc,$(x),$(y))
> $(foo, abc, $(x), $(y))
>
> make is rather annoying as space is significant, but there seems no good 
> reason
> for kconfig to inheritate this.
> So unless there are good arguments consider alloing the spaces.
> If the current implmentation already supports optional spaces then I just 
> missed
> it whie reviewing.
>
> Sam

+1 from me.

I also find the rules for whitespace in Make confusing, and always
have to look them up when doing trickier stuff. Maybe they're the
result of people not considering whitespace initially, and stuff
getting tacked on later. GNU Make adds some alternate syntaxes with
quotes.

I was going to mention shell, but it looks like you already did. :)

If we go with Make-like syntax, maybe we could at least have a variant
with fewer whitespace gotchas.

Cheers,
Ulf

Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='

[Ulf Magnusson]

On Mon, May 21, 2018 at 1:06 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Mon, May 21, 2018 at 6:43 AM, Masahiro Yamada
> <yamada.masah...@socionext.com> wrote:
>> Hi.
>>
>>
>>
>> 2018-05-21 0:46 GMT+09:00 Ulf Magnusson <ulfali...@gmail.com>:
>>
>>> s/environments/environment variables/
>>
>> Will fix.
>>
>>
>>>
>>>> +* They will be written out to include/config/auto.conf.cmd
>>>> +*/
>>>> +   env_add(name, value);
>>>> +
>>>> +   return xstrdup(value);
>>>> +}
>>>> +
>>>> +void env_write_dep(FILE *f, const char *autoconfig_name)
>>>> +{
>>>> +   struct env *e, *tmp;
>>>> +
>>>> +   list_for_each_entry_safe(e, tmp, _list, node) {
>>>> +   fprintf(f, "ifneq \"$(%s)\" \"%s\"\n", e->name, e->value);
>>>> +   fprintf(f, "%s: FORCE\n", autoconfig_name);
>>>> +   fprintf(f, "endif\n");
>>>> +   env_del(e);
>>>> +   }
>>>> +}
>>>> +
>>>> +static char *eval_clause(const char *in)
>>>> +{
>>>> +   char *res, *name;
>>>> +
>>>> +   /*
>>>> +* Returns an empty string because '$()' should be evaluated
>>>> +* to a null string.
>>>> +*/
>>>
>>> Do you know of cases where this is more useful than erroring out?
>>>
>>> Not saying it doesn't make sense. Just curious.
>>
>>
>> I just followed how Make works.
>>
>> Anyway, eval_clause() will return null string for null input.
>> I will remove that hunk.
>>
>>
>>
>>
>>>> +   if (!*in)
>>>> +   return xstrdup("");
>>>> +
>>>> +   name = expand_string(in);
>>>> +
>>>> +   res = env_expand(name);
>>>> +   free(name);
>>>> +
>>>> +   return res;
>>>> +}
>>>> +
>>>> +/*
>>>> + * Expand a string that follows '$'
>>>> + *
>>>> + * For example, if the input string is
>>>> + * ($(FOO)$($(BAR)))$(BAZ)
>>>> + * this helper evaluates
>>>> + * $($(FOO)$($(BAR)))
>>>> + * and returns the resulted string, then updates 'str' to point to the 
>>>> next
>>>
>>> s/resulted/resulting/
>>>
>>> Maybe something like this would make the behavior a bit clearer:
>>>
>>>   ...and returns a new string containing the expansion, also advancing
>>>   'str' to point to the next character after... (note that this function 
>>> does
>>>   a recursive expansion) ...
>>
>>
>> Is this OK?
>>
>> /*
>>  * Expand a string that follows '$'
>>  *
>>  * For example, if the input string is
>>  * ($(FOO)$($(BAR)))$(BAZ)
>>  * this helper evaluates
>>  * $($(FOO)$($(BAR)))
>>  * and returns a new string containing the expansion (note that the string is
>>  * recursively expanded), also advancing 'str' to point to the next character
>>  * after the corresponding closing parenthesis, in this case, *str will be
>>  * $(BAR)
>>  */
>
> Looks fine to me.
>
>>
>>
>>
>>>> + * character after the corresponding closing parenthesis, in this case, 
>>>> *str
>>>> + * will be
>>>> + * $(BAR)
>>>> + */
>>>> +char *expand_dollar(const char **str)
>>>> +{
>>>> +   const char *p = *str;
>>>> +   const char *q;
>>>> +   char *tmp, *out;
>>>> +   int nest = 0;
>>>> +
>>>> +   /* '$$' represents an escaped '$' */
>>>> +   if (*p == '$') {
>>>> +   *str = p + 1;
>>>> +   return xstrdup("$");
>>>> +   }
>>>> +
>>>> +   /*
>>>> +* Kconfig does not support single-letter variable as in $A
>>>> +* or curly braces as in ${CC}.
>>>> +*/
>>>> +   if (*p != '(')
>>>> +   pperror("syntax error: '$' not followed by '('", p);
>>>
>>> Could say "not followed by '(' by or '$'".
>>

Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='

[Ulf Magnusson]

On Mon, May 21, 2018 at 1:06 PM, Ulf Magnusson  wrote:
> On Mon, May 21, 2018 at 6:43 AM, Masahiro Yamada
>  wrote:
>> Hi.
>>
>>
>>
>> 2018-05-21 0:46 GMT+09:00 Ulf Magnusson :
>>
>>> s/environments/environment variables/
>>
>> Will fix.
>>
>>
>>>
>>>> +* They will be written out to include/config/auto.conf.cmd
>>>> +*/
>>>> +   env_add(name, value);
>>>> +
>>>> +   return xstrdup(value);
>>>> +}
>>>> +
>>>> +void env_write_dep(FILE *f, const char *autoconfig_name)
>>>> +{
>>>> +   struct env *e, *tmp;
>>>> +
>>>> +   list_for_each_entry_safe(e, tmp, _list, node) {
>>>> +   fprintf(f, "ifneq \"$(%s)\" \"%s\"\n", e->name, e->value);
>>>> +   fprintf(f, "%s: FORCE\n", autoconfig_name);
>>>> +   fprintf(f, "endif\n");
>>>> +   env_del(e);
>>>> +   }
>>>> +}
>>>> +
>>>> +static char *eval_clause(const char *in)
>>>> +{
>>>> +   char *res, *name;
>>>> +
>>>> +   /*
>>>> +* Returns an empty string because '$()' should be evaluated
>>>> +* to a null string.
>>>> +*/
>>>
>>> Do you know of cases where this is more useful than erroring out?
>>>
>>> Not saying it doesn't make sense. Just curious.
>>
>>
>> I just followed how Make works.
>>
>> Anyway, eval_clause() will return null string for null input.
>> I will remove that hunk.
>>
>>
>>
>>
>>>> +   if (!*in)
>>>> +   return xstrdup("");
>>>> +
>>>> +   name = expand_string(in);
>>>> +
>>>> +   res = env_expand(name);
>>>> +   free(name);
>>>> +
>>>> +   return res;
>>>> +}
>>>> +
>>>> +/*
>>>> + * Expand a string that follows '$'
>>>> + *
>>>> + * For example, if the input string is
>>>> + * ($(FOO)$($(BAR)))$(BAZ)
>>>> + * this helper evaluates
>>>> + * $($(FOO)$($(BAR)))
>>>> + * and returns the resulted string, then updates 'str' to point to the 
>>>> next
>>>
>>> s/resulted/resulting/
>>>
>>> Maybe something like this would make the behavior a bit clearer:
>>>
>>>   ...and returns a new string containing the expansion, also advancing
>>>   'str' to point to the next character after... (note that this function 
>>> does
>>>   a recursive expansion) ...
>>
>>
>> Is this OK?
>>
>> /*
>>  * Expand a string that follows '$'
>>  *
>>  * For example, if the input string is
>>  * ($(FOO)$($(BAR)))$(BAZ)
>>  * this helper evaluates
>>  * $($(FOO)$($(BAR)))
>>  * and returns a new string containing the expansion (note that the string is
>>  * recursively expanded), also advancing 'str' to point to the next character
>>  * after the corresponding closing parenthesis, in this case, *str will be
>>  * $(BAR)
>>  */
>
> Looks fine to me.
>
>>
>>
>>
>>>> + * character after the corresponding closing parenthesis, in this case, 
>>>> *str
>>>> + * will be
>>>> + * $(BAR)
>>>> + */
>>>> +char *expand_dollar(const char **str)
>>>> +{
>>>> +   const char *p = *str;
>>>> +   const char *q;
>>>> +   char *tmp, *out;
>>>> +   int nest = 0;
>>>> +
>>>> +   /* '$$' represents an escaped '$' */
>>>> +   if (*p == '$') {
>>>> +   *str = p + 1;
>>>> +   return xstrdup("$");
>>>> +   }
>>>> +
>>>> +   /*
>>>> +* Kconfig does not support single-letter variable as in $A
>>>> +* or curly braces as in ${CC}.
>>>> +*/
>>>> +   if (*p != '(')
>>>> +   pperror("syntax error: '$' not followed by '('", p);
>>>
>>> Could say "not followed by '(' by or '$'".
>>
>> Will do.
>>
>>
>>>> +
>>>> +   p++;
>>>> +   q = p;
>>>> +   

Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='

[Ulf Magnusson]

On Mon, May 21, 2018 at 6:43 AM, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> Hi.
>
>
>
> 2018-05-21 0:46 GMT+09:00 Ulf Magnusson <ulfali...@gmail.com>:
>
>> s/environments/environment variables/
>
> Will fix.
>
>
>>
>>> +* They will be written out to include/config/auto.conf.cmd
>>> +*/
>>> +   env_add(name, value);
>>> +
>>> +   return xstrdup(value);
>>> +}
>>> +
>>> +void env_write_dep(FILE *f, const char *autoconfig_name)
>>> +{
>>> +   struct env *e, *tmp;
>>> +
>>> +   list_for_each_entry_safe(e, tmp, _list, node) {
>>> +   fprintf(f, "ifneq \"$(%s)\" \"%s\"\n", e->name, e->value);
>>> +   fprintf(f, "%s: FORCE\n", autoconfig_name);
>>> +   fprintf(f, "endif\n");
>>> +   env_del(e);
>>> +   }
>>> +}
>>> +
>>> +static char *eval_clause(const char *in)
>>> +{
>>> +   char *res, *name;
>>> +
>>> +   /*
>>> +* Returns an empty string because '$()' should be evaluated
>>> +* to a null string.
>>> +*/
>>
>> Do you know of cases where this is more useful than erroring out?
>>
>> Not saying it doesn't make sense. Just curious.
>
>
> I just followed how Make works.
>
> Anyway, eval_clause() will return null string for null input.
> I will remove that hunk.
>
>
>
>
>>> +   if (!*in)
>>> +   return xstrdup("");
>>> +
>>> +   name = expand_string(in);
>>> +
>>> +   res = env_expand(name);
>>> +   free(name);
>>> +
>>> +   return res;
>>> +}
>>> +
>>> +/*
>>> + * Expand a string that follows '$'
>>> + *
>>> + * For example, if the input string is
>>> + * ($(FOO)$($(BAR)))$(BAZ)
>>> + * this helper evaluates
>>> + * $($(FOO)$($(BAR)))
>>> + * and returns the resulted string, then updates 'str' to point to the next
>>
>> s/resulted/resulting/
>>
>> Maybe something like this would make the behavior a bit clearer:
>>
>>   ...and returns a new string containing the expansion, also advancing
>>   'str' to point to the next character after... (note that this function does
>>   a recursive expansion) ...
>
>
> Is this OK?
>
> /*
>  * Expand a string that follows '$'
>  *
>  * For example, if the input string is
>  * ($(FOO)$($(BAR)))$(BAZ)
>  * this helper evaluates
>  * $($(FOO)$($(BAR)))
>  * and returns a new string containing the expansion (note that the string is
>  * recursively expanded), also advancing 'str' to point to the next character
>  * after the corresponding closing parenthesis, in this case, *str will be
>  * $(BAR)
>  */

Looks fine to me.

>
>
>
>>> + * character after the corresponding closing parenthesis, in this case, 
>>> *str
>>> + * will be
>>> + * $(BAR)
>>> + */
>>> +char *expand_dollar(const char **str)
>>> +{
>>> +   const char *p = *str;
>>> +   const char *q;
>>> +   char *tmp, *out;
>>> +   int nest = 0;
>>> +
>>> +   /* '$$' represents an escaped '$' */
>>> +   if (*p == '$') {
>>> +   *str = p + 1;
>>> +   return xstrdup("$");
>>> +   }
>>> +
>>> +   /*
>>> +* Kconfig does not support single-letter variable as in $A
>>> +* or curly braces as in ${CC}.
>>> +*/
>>> +   if (*p != '(')
>>> +   pperror("syntax error: '$' not followed by '('", p);
>>
>> Could say "not followed by '(' by or '$'".
>
> Will do.
>
>
>>> +
>>> +   p++;
>>> +   q = p;
>>> +   while (*q) {
>>> +   if (*q == '(') {
>>> +   nest++;
>>> +   } else if (*q == ')') {
>>> +   if (nest-- == 0)
>>> +   break;
>>> +   }
>>> +   q++;
>>> +   }
>>> +
>>> +   if (!*q)
>>> +   pperror("unterminated reference to '%s': missing ')'", p);
>>> +
>>> +   tmp = xmalloc(q - p + 1);
>>> +   memc

Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='

[Ulf Magnusson]

On Mon, May 21, 2018 at 6:43 AM, Masahiro Yamada
 wrote:
> Hi.
>
>
>
> 2018-05-21 0:46 GMT+09:00 Ulf Magnusson :
>
>> s/environments/environment variables/
>
> Will fix.
>
>
>>
>>> +* They will be written out to include/config/auto.conf.cmd
>>> +*/
>>> +   env_add(name, value);
>>> +
>>> +   return xstrdup(value);
>>> +}
>>> +
>>> +void env_write_dep(FILE *f, const char *autoconfig_name)
>>> +{
>>> +   struct env *e, *tmp;
>>> +
>>> +   list_for_each_entry_safe(e, tmp, _list, node) {
>>> +   fprintf(f, "ifneq \"$(%s)\" \"%s\"\n", e->name, e->value);
>>> +   fprintf(f, "%s: FORCE\n", autoconfig_name);
>>> +   fprintf(f, "endif\n");
>>> +   env_del(e);
>>> +   }
>>> +}
>>> +
>>> +static char *eval_clause(const char *in)
>>> +{
>>> +   char *res, *name;
>>> +
>>> +   /*
>>> +* Returns an empty string because '$()' should be evaluated
>>> +* to a null string.
>>> +*/
>>
>> Do you know of cases where this is more useful than erroring out?
>>
>> Not saying it doesn't make sense. Just curious.
>
>
> I just followed how Make works.
>
> Anyway, eval_clause() will return null string for null input.
> I will remove that hunk.
>
>
>
>
>>> +   if (!*in)
>>> +   return xstrdup("");
>>> +
>>> +   name = expand_string(in);
>>> +
>>> +   res = env_expand(name);
>>> +   free(name);
>>> +
>>> +   return res;
>>> +}
>>> +
>>> +/*
>>> + * Expand a string that follows '$'
>>> + *
>>> + * For example, if the input string is
>>> + * ($(FOO)$($(BAR)))$(BAZ)
>>> + * this helper evaluates
>>> + * $($(FOO)$($(BAR)))
>>> + * and returns the resulted string, then updates 'str' to point to the next
>>
>> s/resulted/resulting/
>>
>> Maybe something like this would make the behavior a bit clearer:
>>
>>   ...and returns a new string containing the expansion, also advancing
>>   'str' to point to the next character after... (note that this function does
>>   a recursive expansion) ...
>
>
> Is this OK?
>
> /*
>  * Expand a string that follows '$'
>  *
>  * For example, if the input string is
>  * ($(FOO)$($(BAR)))$(BAZ)
>  * this helper evaluates
>  * $($(FOO)$($(BAR)))
>  * and returns a new string containing the expansion (note that the string is
>  * recursively expanded), also advancing 'str' to point to the next character
>  * after the corresponding closing parenthesis, in this case, *str will be
>  * $(BAR)
>  */

Looks fine to me.

>
>
>
>>> + * character after the corresponding closing parenthesis, in this case, 
>>> *str
>>> + * will be
>>> + * $(BAR)
>>> + */
>>> +char *expand_dollar(const char **str)
>>> +{
>>> +   const char *p = *str;
>>> +   const char *q;
>>> +   char *tmp, *out;
>>> +   int nest = 0;
>>> +
>>> +   /* '$$' represents an escaped '$' */
>>> +   if (*p == '$') {
>>> +   *str = p + 1;
>>> +   return xstrdup("$");
>>> +   }
>>> +
>>> +   /*
>>> +* Kconfig does not support single-letter variable as in $A
>>> +* or curly braces as in ${CC}.
>>> +*/
>>> +   if (*p != '(')
>>> +   pperror("syntax error: '$' not followed by '('", p);
>>
>> Could say "not followed by '(' by or '$'".
>
> Will do.
>
>
>>> +
>>> +   p++;
>>> +   q = p;
>>> +   while (*q) {
>>> +   if (*q == '(') {
>>> +   nest++;
>>> +   } else if (*q == ')') {
>>> +   if (nest-- == 0)
>>> +   break;
>>> +   }
>>> +   q++;
>>> +   }
>>> +
>>> +   if (!*q)
>>> +   pperror("unterminated reference to '%s': missing ')'", p);
>>> +
>>> +   tmp = xmalloc(q - p + 1);
>>> +   memcpy(tmp, p, q - p);
>>> +   tmp[q - p] = 0

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Mon, May 21, 2018 at 4:45 AM, Randy Dunlap <rdun...@infradead.org> wrote:
> On 05/19/2018 09:47 PM, Ulf Magnusson wrote:
>> On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap <rdun...@infradead.org> wrote:
>>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>>>> Hello,
>>>>>
>>>>> I've added incremental search for jumping directly to a symbol now.
>>>>> Regular expressions are supported as well.
>>>>>
>>>>> Some screenshots below:
>>>>>
>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>>>
>>>>> The last screenshot shows how things might look after you jump to a
>>>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>>>> mode was turned on automatically.
>>>>
>>>> Hi Ulf,
>>>>
>>>>
>>>>
>>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the 
>>>> UI now.
>>>>
>>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>>> Kconfiglib/menuconfig.py
>>>>
>>>> so yes, a real Makefile target would be nice. :)
>>>
>>> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
>>> _DEBUGFS).  Using:
>>>
>>> /.*_DEBUG$
>>>
>>> shows me 6 symbols:
>>> ATH9K_COMMON_DEBUG
>>> DVB_B2C2_FLEXCOP_DEBUG
>>> HAVE_DMA_API_DEBUG
>>> IP_DCCP_TFRC_DEBUG
>>> NFS_DEBUG
>>> PM_SLEEP_DEBUG
>>>
>>> so where are the other (approx.) 176?
>>> see:
>>> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | 
>>> wc
>>> 182 3649179
>>>
>>>
>>> Anyway, something for you to look at. :)
>>>
>>> --
>>> ~Randy
>>
>> It's related to how the search is done. Searching for "DEBUG\b" (word
>> boundary) instead will find all of them.
>>
>> A string is generated for each symbol. For symbols with prompts, this
>> string includes the prompt as well, so you get e.g.
>>
>> AB8500_DEBUG "Enable debug info via debugfs"
>>
>> Those strings are then searched/displayed.
>>
>> What you got with your search was all symbols whose names end in
>> "_DEBUG" that don't have a prompt.
>>
>> The nice thing about searching both the name and the prompt is that
>> e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
>> add menus to the search, by generating 'menu: "menu title"' strings
>> for them.
>>
>> It's a bit awkward/unintuitive that what you tried doesn't work
>> though. Maybe the symbol name could be searched separately from the
>> prompt, though I'd be a bit sad to abandon the super simple
>> single-string-per-entry implementation approach. :)
>
> Hi Ulf,
>
> What else are you planning to do with /(search)?

Here's the stuff I've thought of so far:

  - Display invisible symbols in red (to match show-all mode)

  - Search prompts of menus and comments as well

  - Have [F1] show the help display without canceling the search,
so you can quickly scan through a bunch of symbols

Maybe you could get fancy with stuff like finding symbols that are
related to other symbols in particular ways too...

> /syscall lists 20 or so symbols. It would be nice if each one of those
> showed its current setting [y,n,maybe^Wm].

Nice idea. I added it:
https://github.com/ulfalizer/Kconfiglib/commit/3161affaa5bb8350a39bfd305c56171a25b02151

Works for strings/int/hex too.

> I like Toggle show-all mode.  When I use xconfig, I usually turn on most
> of its options, including one like that.

IIRC, xconfig doesn't make it very clear which symbols are invisible
in show-all mode. That's why I made them red.

>
> --
> ~Randy

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Mon, May 21, 2018 at 4:45 AM, Randy Dunlap  wrote:
> On 05/19/2018 09:47 PM, Ulf Magnusson wrote:
>> On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap  wrote:
>>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>>>> Hello,
>>>>>
>>>>> I've added incremental search for jumping directly to a symbol now.
>>>>> Regular expressions are supported as well.
>>>>>
>>>>> Some screenshots below:
>>>>>
>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>>>
>>>>> The last screenshot shows how things might look after you jump to a
>>>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>>>> mode was turned on automatically.
>>>>
>>>> Hi Ulf,
>>>>
>>>>
>>>>
>>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the 
>>>> UI now.
>>>>
>>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>>> Kconfiglib/menuconfig.py
>>>>
>>>> so yes, a real Makefile target would be nice. :)
>>>
>>> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
>>> _DEBUGFS).  Using:
>>>
>>> /.*_DEBUG$
>>>
>>> shows me 6 symbols:
>>> ATH9K_COMMON_DEBUG
>>> DVB_B2C2_FLEXCOP_DEBUG
>>> HAVE_DMA_API_DEBUG
>>> IP_DCCP_TFRC_DEBUG
>>> NFS_DEBUG
>>> PM_SLEEP_DEBUG
>>>
>>> so where are the other (approx.) 176?
>>> see:
>>> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | 
>>> wc
>>> 182 3649179
>>>
>>>
>>> Anyway, something for you to look at. :)
>>>
>>> --
>>> ~Randy
>>
>> It's related to how the search is done. Searching for "DEBUG\b" (word
>> boundary) instead will find all of them.
>>
>> A string is generated for each symbol. For symbols with prompts, this
>> string includes the prompt as well, so you get e.g.
>>
>> AB8500_DEBUG "Enable debug info via debugfs"
>>
>> Those strings are then searched/displayed.
>>
>> What you got with your search was all symbols whose names end in
>> "_DEBUG" that don't have a prompt.
>>
>> The nice thing about searching both the name and the prompt is that
>> e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
>> add menus to the search, by generating 'menu: "menu title"' strings
>> for them.
>>
>> It's a bit awkward/unintuitive that what you tried doesn't work
>> though. Maybe the symbol name could be searched separately from the
>> prompt, though I'd be a bit sad to abandon the super simple
>> single-string-per-entry implementation approach. :)
>
> Hi Ulf,
>
> What else are you planning to do with /(search)?

Here's the stuff I've thought of so far:

  - Display invisible symbols in red (to match show-all mode)

  - Search prompts of menus and comments as well

  - Have [F1] show the help display without canceling the search,
so you can quickly scan through a bunch of symbols

Maybe you could get fancy with stuff like finding symbols that are
related to other symbols in particular ways too...

> /syscall lists 20 or so symbols. It would be nice if each one of those
> showed its current setting [y,n,maybe^Wm].

Nice idea. I added it:
https://github.com/ulfalizer/Kconfiglib/commit/3161affaa5bb8350a39bfd305c56171a25b02151

Works for strings/int/hex too.

> I like Toggle show-all mode.  When I use xconfig, I usually turn on most
> of its options, including one like that.

IIRC, xconfig doesn't make it very clear which symbols are invisible
in show-all mode. That's why I made them red.

>
> --
> ~Randy

Cheers,
Ulf

Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='

[Ulf Magnusson]

On Thu, May 17, 2018 at 8:16 AM, Masahiro Yamada
 wrote:
> To get access to environment variables, Kconfig needs to define a
> symbol using "option env=" syntax.  It is tedious to add a symbol entry
> for each environment variable given that we need to define much more
> such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
> in Kconfig.
>
> Adding '$' for symbol references is grammatically inconsistent.
> 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'
>  - sym_expand_string_value()
>This is used to expand strings in 'source' and 'mainmenu'
>
> All of them are fixed values independent of user configuration.  So,
> they can be changed into the direct expansion instead of symbols.
>
> 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 replaced with an environment variable.
>
> ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
> without '$' prefix.
>
> The new syntax is addicted by Make.  The variable reference needs
> parentheses, like $(FOO), but you can omit them for single-letter
> variables, like $F.  Yet, in Makefiles, people tend to use the
> parenthetical form for consistency / clarification.
>
> At this moment, only the environment variable is supported, but I will
> extend the concept of 'variable' later on.
>
> The variables are expanded in the lexer so we can simplify the token
> handling on the parser side.
>
> For example, the following code works.
>
> [Example code]
>
>   config MY_TOOLCHAIN_LIST
>   string
>   default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"
>
> [Result]
>
>   $ make -s alldefconfig && tail -n 1 .config
>   CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"
>
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Kees Cook 
> ---
>
> Changes in v4:
>   - Enclose ARCH in conf_defname
>   - Drop single-letter support
>
> Changes in v3:
>   - Reimplement
>   - Variable reference need parentheses except single-letter variable
>
> Changes in v2:
>   - Move the string expansion to the lexer phase.
>   - Split environment helpers to env.c
>
>  Documentation/kbuild/kconfig-language.txt |   8 -
>  Kconfig   |   8 +-
>  Makefile  |   3 +-
>  arch/sh/Kconfig   |   4 +-
>  arch/sparc/Kconfig|   4 +-
>  arch/um/Kconfig.common|   4 -
>  arch/x86/Kconfig  |   4 +-
>  arch/x86/um/Kconfig   |   6 +-
>  init/Kconfig  |  16 +-
>  scripts/kconfig/confdata.c|  33 +---
>  scripts/kconfig/kconf_id.c|   1 -
>  scripts/kconfig/lkc.h |   4 -
>  scripts/kconfig/lkc_proto.h   |   6 +
>  scripts/kconfig/menu.c|   3 -
>  scripts/kconfig/preprocess.c  | 247 
> ++
>  scripts/kconfig/symbol.c  |  56 ---
>  scripts/kconfig/util.c|  18 +--
>  scripts/kconfig/zconf.l   |  67 +++-
>  scripts/kconfig/zconf.y   |   2 +-
>  19 files changed, 340 insertions(+), 154 deletions(-)
>  create mode 100644 scripts/kconfig/preprocess.c
>
> diff --git a/Documentation/kbuild/kconfig-language.txt 
> b/Documentation/kbuild/kconfig-language.txt
> index f5b9493..0e966e8 100644
> --- a/Documentation/kbuild/kconfig-language.txt
> +++ b/Documentation/kbuild/kconfig-language.txt
> @@ -198,14 +198,6 @@ applicable everywhere (see syntax).
>  enables the third modular state for all config symbols.
>  At most one symbol may have the "modules" option set.
>
> -  - "env"=
> -This imports the environment variable into Kconfig. It behaves like
> -a default, except that the value comes from the environment, this
> -also means that the behaviour when mixing it with normal defaults is
> -undefined at this point. The symbol is currently not exported back
> -to the build environment (if this is desired, it can be done via
> -another symbol).
> -
>- "allnoconfig_y"
>  This declares the symbol as one that should have the value y when
>  using "allnoconfig". Used for symbols that hide other symbols.
> diff --git a/Kconfig b/Kconfig
> index 8c4c1cb..4af1b42 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -3,10 +3,6 @@
>  # For a description of the syntax of this configuration file,
>  # see Documentation/kbuild/kconfig-language.txt.
>  #
> -mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"
> +mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
>
> -config SRCARCH
> -   string
> 

Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='

[Ulf Magnusson]

On Thu, May 17, 2018 at 8:16 AM, Masahiro Yamada
 wrote:
> To get access to environment variables, Kconfig needs to define a
> symbol using "option env=" syntax.  It is tedious to add a symbol entry
> for each environment variable given that we need to define much more
> such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
> in Kconfig.
>
> Adding '$' for symbol references is grammatically inconsistent.
> 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'
>  - sym_expand_string_value()
>This is used to expand strings in 'source' and 'mainmenu'
>
> All of them are fixed values independent of user configuration.  So,
> they can be changed into the direct expansion instead of symbols.
>
> 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 replaced with an environment variable.
>
> ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
> without '$' prefix.
>
> The new syntax is addicted by Make.  The variable reference needs
> parentheses, like $(FOO), but you can omit them for single-letter
> variables, like $F.  Yet, in Makefiles, people tend to use the
> parenthetical form for consistency / clarification.
>
> At this moment, only the environment variable is supported, but I will
> extend the concept of 'variable' later on.
>
> The variables are expanded in the lexer so we can simplify the token
> handling on the parser side.
>
> For example, the following code works.
>
> [Example code]
>
>   config MY_TOOLCHAIN_LIST
>   string
>   default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"
>
> [Result]
>
>   $ make -s alldefconfig && tail -n 1 .config
>   CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"
>
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Kees Cook 
> ---
>
> Changes in v4:
>   - Enclose ARCH in conf_defname
>   - Drop single-letter support
>
> Changes in v3:
>   - Reimplement
>   - Variable reference need parentheses except single-letter variable
>
> Changes in v2:
>   - Move the string expansion to the lexer phase.
>   - Split environment helpers to env.c
>
>  Documentation/kbuild/kconfig-language.txt |   8 -
>  Kconfig   |   8 +-
>  Makefile  |   3 +-
>  arch/sh/Kconfig   |   4 +-
>  arch/sparc/Kconfig|   4 +-
>  arch/um/Kconfig.common|   4 -
>  arch/x86/Kconfig  |   4 +-
>  arch/x86/um/Kconfig   |   6 +-
>  init/Kconfig  |  16 +-
>  scripts/kconfig/confdata.c|  33 +---
>  scripts/kconfig/kconf_id.c|   1 -
>  scripts/kconfig/lkc.h |   4 -
>  scripts/kconfig/lkc_proto.h   |   6 +
>  scripts/kconfig/menu.c|   3 -
>  scripts/kconfig/preprocess.c  | 247 
> ++
>  scripts/kconfig/symbol.c  |  56 ---
>  scripts/kconfig/util.c|  18 +--
>  scripts/kconfig/zconf.l   |  67 +++-
>  scripts/kconfig/zconf.y   |   2 +-
>  19 files changed, 340 insertions(+), 154 deletions(-)
>  create mode 100644 scripts/kconfig/preprocess.c
>
> diff --git a/Documentation/kbuild/kconfig-language.txt 
> b/Documentation/kbuild/kconfig-language.txt
> index f5b9493..0e966e8 100644
> --- a/Documentation/kbuild/kconfig-language.txt
> +++ b/Documentation/kbuild/kconfig-language.txt
> @@ -198,14 +198,6 @@ applicable everywhere (see syntax).
>  enables the third modular state for all config symbols.
>  At most one symbol may have the "modules" option set.
>
> -  - "env"=
> -This imports the environment variable into Kconfig. It behaves like
> -a default, except that the value comes from the environment, this
> -also means that the behaviour when mixing it with normal defaults is
> -undefined at this point. The symbol is currently not exported back
> -to the build environment (if this is desired, it can be done via
> -another symbol).
> -
>- "allnoconfig_y"
>  This declares the symbol as one that should have the value y when
>  using "allnoconfig". Used for symbols that hide other symbols.
> diff --git a/Kconfig b/Kconfig
> index 8c4c1cb..4af1b42 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -3,10 +3,6 @@
>  # For a description of the syntax of this configuration file,
>  # see Documentation/kbuild/kconfig-language.txt.
>  #
> -mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"
> +mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
>
> -config SRCARCH
> -   string
> -   option env="SRCARCH"
> -
> -source "arch/$SRCARCH/Kconfig"
> +source 

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap <rdun...@infradead.org> wrote:
> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> I've added incremental search for jumping directly to a symbol now.
>>> Regular expressions are supported as well.
>>>
>>> Some screenshots below:
>>>
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>
>>> The last screenshot shows how things might look after you jump to a
>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>> mode was turned on automatically.
>>
>> Hi Ulf,
>>
>>
>>
>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
>> now.
>>
>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>> Kconfiglib/menuconfig.py
>>
>> so yes, a real Makefile target would be nice. :)
>
> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
> _DEBUGFS).  Using:
>
> /.*_DEBUG$
>
> shows me 6 symbols:
> ATH9K_COMMON_DEBUG
> DVB_B2C2_FLEXCOP_DEBUG
> HAVE_DMA_API_DEBUG
> IP_DCCP_TFRC_DEBUG
> NFS_DEBUG
> PM_SLEEP_DEBUG
>
> so where are the other (approx.) 176?
> see:
> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
> 182 3649179
>
>
> Anyway, something for you to look at. :)
>
> --
> ~Randy

I changed it to search the symbol name and the prompt separately:
https://github.com/ulfalizer/Kconfiglib/commit/e0905818ef376c977d0a4540ea72d61b8f554bb5

Should work the way you expected now. It's more intuitive for the prompt too. :)

Can just do 'debug$' by the way. No '.*' required.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap  wrote:
> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> I've added incremental search for jumping directly to a symbol now.
>>> Regular expressions are supported as well.
>>>
>>> Some screenshots below:
>>>
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>
>>> The last screenshot shows how things might look after you jump to a
>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>> mode was turned on automatically.
>>
>> Hi Ulf,
>>
>>
>>
>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
>> now.
>>
>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>> Kconfiglib/menuconfig.py
>>
>> so yes, a real Makefile target would be nice. :)
>
> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
> _DEBUGFS).  Using:
>
> /.*_DEBUG$
>
> shows me 6 symbols:
> ATH9K_COMMON_DEBUG
> DVB_B2C2_FLEXCOP_DEBUG
> HAVE_DMA_API_DEBUG
> IP_DCCP_TFRC_DEBUG
> NFS_DEBUG
> PM_SLEEP_DEBUG
>
> so where are the other (approx.) 176?
> see:
> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
> 182 3649179
>
>
> Anyway, something for you to look at. :)
>
> --
> ~Randy

I changed it to search the symbol name and the prompt separately:
https://github.com/ulfalizer/Kconfiglib/commit/e0905818ef376c977d0a4540ea72d61b8f554bb5

Should work the way you expected now. It's more intuitive for the prompt too. :)

Can just do 'debug$' by the way. No '.*' required.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 5:45 AM, Randy Dunlap <rdun...@infradead.org> wrote:
> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>> Hello,
>>
>> I've added incremental search for jumping directly to a symbol now.
>> Regular expressions are supported as well.
>>
>> Some screenshots below:
>>
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>
>> The last screenshot shows how things might look after you jump to a
>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>> mode was turned on automatically.
>
> Hi Ulf,
>
> Do I need to save kconfiglib.py in a special location?
>
> With (new) kconfiglib.py and menuconfig.py, I am getting this:
>
> $ make ARCH=x86_64 O=xx64 iscriptconfig
> make[1]: Entering directory '/home/rdunlap/lnx/lnx-417-rc3/xx64'
>   GEN ./Makefile
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named 'kconfiglib'
>>>>
>
> and then if I (being a Python novice) copy kconfiglib.py to
> /usr/lib/python3.4/site-packages/ and try again, I get 16 warning messages 
> (below)
> and then this:
>
> A Kconfig instance 'kconf' for the architecture x86_64 has been created.
>>>>
>
> What am I supposed to do now?
>
> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
> now.
>
> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
> Kconfiglib/menuconfig.py
>
> so yes, a real Makefile target would be nice. :)

Gonna get around to it soon. It's a bit silly that you don't get the
menuconfig through the 'pip' install either. :)

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 5:45 AM, Randy Dunlap  wrote:
> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>> Hello,
>>
>> I've added incremental search for jumping directly to a symbol now.
>> Regular expressions are supported as well.
>>
>> Some screenshots below:
>>
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>
>> The last screenshot shows how things might look after you jump to a
>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>> mode was turned on automatically.
>
> Hi Ulf,
>
> Do I need to save kconfiglib.py in a special location?
>
> With (new) kconfiglib.py and menuconfig.py, I am getting this:
>
> $ make ARCH=x86_64 O=xx64 iscriptconfig
> make[1]: Entering directory '/home/rdunlap/lnx/lnx-417-rc3/xx64'
>   GEN ./Makefile
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named 'kconfiglib'
>>>>
>
> and then if I (being a Python novice) copy kconfiglib.py to
> /usr/lib/python3.4/site-packages/ and try again, I get 16 warning messages 
> (below)
> and then this:
>
> A Kconfig instance 'kconf' for the architecture x86_64 has been created.
>>>>
>
> What am I supposed to do now?
>
> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
> now.
>
> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
> Kconfiglib/menuconfig.py
>
> so yes, a real Makefile target would be nice. :)

Gonna get around to it soon. It's a bit silly that you don't get the
menuconfig through the 'pip' install either. :)

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:24 AM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Sun, May 20, 2018 at 5:51 AM, Randy Dunlap <rdun...@infradead.org> wrote:
>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> I've added incremental search for jumping directly to a symbol now.
>>>> Regular expressions are supported as well.
>>>>
>>>> Some screenshots below:
>>>>
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>>
>>>> The last screenshot shows how things might look after you jump to a
>>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>>> mode was turned on automatically.
>>>
>>> Hi Ulf,
>>>
>>>
>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the 
>>> UI now.
>>>
>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>> Kconfiglib/menuconfig.py
>>>
>>> so yes, a real Makefile target would be nice. :)
>>
>>
>> Enter: / (search)
>> then:  * (Bang) [this was just an unlucky typo on my part]
>>
>> Traceback (most recent call last):
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in _jump_to_dialog
>> for regex in s.split()]
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in 
>> for regex in s.split()]
>>   File "/usr/lib64/python3.4/re.py", line 223, in compile
>> return _compile(pattern, flags)
>>   File "/usr/lib64/python3.4/re.py", line 294, in _compile
>> p = sre_compile.compile(pattern, flags)
>>   File "/usr/lib64/python3.4/sre_compile.py", line 568, in compile
>> p = sre_parse.parse(p, flags)
>>   File "/usr/lib64/python3.4/sre_parse.py", line 780, in parse
>> p = _parse_sub(source, pattern, 0)
>>   File "/usr/lib64/python3.4/sre_parse.py", line 377, in _parse_sub
>> itemsappend(_parse(source, state))
>>   File "/usr/lib64/python3.4/sre_parse.py", line 586, in _parse
>> raise error("nothing to repeat")
>> sre_constants.error: nothing to repeat
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>>   File "/home/rdunlap/scripts/menuconfig.py", line 2389, in 
>> menuconfig(Kconfig("Kconfig" if len(sys.argv) < 2 else sys.argv[1]))
>>   File "/home/rdunlap/scripts/menuconfig.py", line 340, in menuconfig
>> print(curses.wrapper(_menuconfig))
>>   File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
>> return func(stdscr, *args, **kwds)
>>   File "/home/rdunlap/scripts/menuconfig.py", line 483, in _menuconfig
>> _jump_to_dialog()
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1466, in _jump_to_dialog
>> bad_re = e.msg
>> AttributeError: 'error' object has no attribute 'msg'
>>
>>
>>
>> --
>> ~Randy
>
> Thanks for the report!
>
> Invalid regular expressions are detected, but it looks like the 'msg'
> field of re.error was added in Python 3.5 (you have 3.4).
>
> I'll check if the 'msg' field exists and fall back to just printing
> "Invalid regular expression" otherwise. The 'msg' field just gives a
> more informative error
> ("Bad regular expression: nothing to repeat" in this case).
>
> Cheers,
> Ulf

Fixed: 
https://github.com/ulfalizer/Kconfiglib/commit/3072e7338cfc63f2f81f34d02edc34dab3d9f365

Your environment seems to have a knack for finding stuff like that.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:24 AM, Ulf Magnusson  wrote:
> On Sun, May 20, 2018 at 5:51 AM, Randy Dunlap  wrote:
>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> I've added incremental search for jumping directly to a symbol now.
>>>> Regular expressions are supported as well.
>>>>
>>>> Some screenshots below:
>>>>
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>>
>>>> The last screenshot shows how things might look after you jump to a
>>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>>> mode was turned on automatically.
>>>
>>> Hi Ulf,
>>>
>>>
>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the 
>>> UI now.
>>>
>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>> Kconfiglib/menuconfig.py
>>>
>>> so yes, a real Makefile target would be nice. :)
>>
>>
>> Enter: / (search)
>> then:  * (Bang) [this was just an unlucky typo on my part]
>>
>> Traceback (most recent call last):
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in _jump_to_dialog
>> for regex in s.split()]
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in 
>> for regex in s.split()]
>>   File "/usr/lib64/python3.4/re.py", line 223, in compile
>> return _compile(pattern, flags)
>>   File "/usr/lib64/python3.4/re.py", line 294, in _compile
>> p = sre_compile.compile(pattern, flags)
>>   File "/usr/lib64/python3.4/sre_compile.py", line 568, in compile
>> p = sre_parse.parse(p, flags)
>>   File "/usr/lib64/python3.4/sre_parse.py", line 780, in parse
>> p = _parse_sub(source, pattern, 0)
>>   File "/usr/lib64/python3.4/sre_parse.py", line 377, in _parse_sub
>> itemsappend(_parse(source, state))
>>   File "/usr/lib64/python3.4/sre_parse.py", line 586, in _parse
>> raise error("nothing to repeat")
>> sre_constants.error: nothing to repeat
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>>   File "/home/rdunlap/scripts/menuconfig.py", line 2389, in 
>> menuconfig(Kconfig("Kconfig" if len(sys.argv) < 2 else sys.argv[1]))
>>   File "/home/rdunlap/scripts/menuconfig.py", line 340, in menuconfig
>> print(curses.wrapper(_menuconfig))
>>   File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
>> return func(stdscr, *args, **kwds)
>>   File "/home/rdunlap/scripts/menuconfig.py", line 483, in _menuconfig
>> _jump_to_dialog()
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1466, in _jump_to_dialog
>> bad_re = e.msg
>> AttributeError: 'error' object has no attribute 'msg'
>>
>>
>>
>> --
>> ~Randy
>
> Thanks for the report!
>
> Invalid regular expressions are detected, but it looks like the 'msg'
> field of re.error was added in Python 3.5 (you have 3.4).
>
> I'll check if the 'msg' field exists and fall back to just printing
> "Invalid regular expression" otherwise. The 'msg' field just gives a
> more informative error
> ("Bad regular expression: nothing to repeat" in this case).
>
> Cheers,
> Ulf

Fixed: 
https://github.com/ulfalizer/Kconfiglib/commit/3072e7338cfc63f2f81f34d02edc34dab3d9f365

Your environment seems to have a knack for finding stuff like that.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:47 AM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap <rdun...@infradead.org> wrote:
>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> I've added incremental search for jumping directly to a symbol now.
>>>> Regular expressions are supported as well.
>>>>
>>>> Some screenshots below:
>>>>
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>>
>>>> The last screenshot shows how things might look after you jump to a
>>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>>> mode was turned on automatically.
>>>
>>> Hi Ulf,
>>>
>>>
>>>
>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the 
>>> UI now.
>>>
>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>> Kconfiglib/menuconfig.py
>>>
>>> so yes, a real Makefile target would be nice. :)
>>
>> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
>> _DEBUGFS).  Using:
>>
>> /.*_DEBUG$
>>
>> shows me 6 symbols:
>> ATH9K_COMMON_DEBUG
>> DVB_B2C2_FLEXCOP_DEBUG
>> HAVE_DMA_API_DEBUG
>> IP_DCCP_TFRC_DEBUG
>> NFS_DEBUG
>> PM_SLEEP_DEBUG
>>
>> so where are the other (approx.) 176?
>> see:
>> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
>> 182 3649179
>>
>>
>> Anyway, something for you to look at. :)
>>
>> --
>> ~Randy
>
> It's related to how the search is done. Searching for "DEBUG\b" (word
> boundary) instead will find all of them.
>
> A string is generated for each symbol. For symbols with prompts, this
> string includes the prompt as well, so you get e.g.
>
> AB8500_DEBUG "Enable debug info via debugfs"
>
> Those strings are then searched/displayed.
>
> What you got with your search was all symbols whose names end in
> "_DEBUG" that don't have a prompt.
>
> The nice thing about searching both the name and the prompt is that
> e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
> add menus to the search, by generating 'menu: "menu title"' strings
> for them.
>
> It's a bit awkward/unintuitive that what you tried doesn't work
> though. Maybe the symbol name could be searched separately from the
> prompt, though I'd be a bit sad to abandon the super simple
> single-string-per-entry implementation approach. :)
>
> Thanks,
> Ulf

Need to make that "_DEBUG\b" to avoid getting a bunch of hits in prompts though.

Searching the name separately from the prompt might give nicer
behavior when regexes are involved. People might not expect e.g.
'debug.*info' to match for AB8500_DEBUG either, but it would, because
the prompt has "info" in it. OTOH, for searches like that, you'd
usually just type "debug info", and then narrow it down with more
words.

Any opinions?

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:47 AM, Ulf Magnusson  wrote:
> On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap  wrote:
>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> I've added incremental search for jumping directly to a symbol now.
>>>> Regular expressions are supported as well.
>>>>
>>>> Some screenshots below:
>>>>
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>>
>>>> The last screenshot shows how things might look after you jump to a
>>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>>> mode was turned on automatically.
>>>
>>> Hi Ulf,
>>>
>>>
>>>
>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the 
>>> UI now.
>>>
>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>> Kconfiglib/menuconfig.py
>>>
>>> so yes, a real Makefile target would be nice. :)
>>
>> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
>> _DEBUGFS).  Using:
>>
>> /.*_DEBUG$
>>
>> shows me 6 symbols:
>> ATH9K_COMMON_DEBUG
>> DVB_B2C2_FLEXCOP_DEBUG
>> HAVE_DMA_API_DEBUG
>> IP_DCCP_TFRC_DEBUG
>> NFS_DEBUG
>> PM_SLEEP_DEBUG
>>
>> so where are the other (approx.) 176?
>> see:
>> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
>> 182 3649179
>>
>>
>> Anyway, something for you to look at. :)
>>
>> --
>> ~Randy
>
> It's related to how the search is done. Searching for "DEBUG\b" (word
> boundary) instead will find all of them.
>
> A string is generated for each symbol. For symbols with prompts, this
> string includes the prompt as well, so you get e.g.
>
> AB8500_DEBUG "Enable debug info via debugfs"
>
> Those strings are then searched/displayed.
>
> What you got with your search was all symbols whose names end in
> "_DEBUG" that don't have a prompt.
>
> The nice thing about searching both the name and the prompt is that
> e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
> add menus to the search, by generating 'menu: "menu title"' strings
> for them.
>
> It's a bit awkward/unintuitive that what you tried doesn't work
> though. Maybe the symbol name could be searched separately from the
> prompt, though I'd be a bit sad to abandon the super simple
> single-string-per-entry implementation approach. :)
>
> Thanks,
> Ulf

Need to make that "_DEBUG\b" to avoid getting a bunch of hits in prompts though.

Searching the name separately from the prompt might give nicer
behavior when regexes are involved. People might not expect e.g.
'debug.*info' to match for AB8500_DEBUG either, but it would, because
the prompt has "info" in it. OTOH, for searches like that, you'd
usually just type "debug info", and then narrow it down with more
words.

Any opinions?

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap <rdun...@infradead.org> wrote:
> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> I've added incremental search for jumping directly to a symbol now.
>>> Regular expressions are supported as well.
>>>
>>> Some screenshots below:
>>>
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>
>>> The last screenshot shows how things might look after you jump to a
>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>> mode was turned on automatically.
>>
>> Hi Ulf,
>>
>>
>>
>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
>> now.
>>
>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>> Kconfiglib/menuconfig.py
>>
>> so yes, a real Makefile target would be nice. :)
>
> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
> _DEBUGFS).  Using:
>
> /.*_DEBUG$
>
> shows me 6 symbols:
> ATH9K_COMMON_DEBUG
> DVB_B2C2_FLEXCOP_DEBUG
> HAVE_DMA_API_DEBUG
> IP_DCCP_TFRC_DEBUG
> NFS_DEBUG
> PM_SLEEP_DEBUG
>
> so where are the other (approx.) 176?
> see:
> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
> 182 3649179
>
>
> Anyway, something for you to look at. :)
>
> --
> ~Randy

It's related to how the search is done. Searching for "DEBUG\b" (word
boundary) instead will find all of them.

A string is generated for each symbol. For symbols with prompts, this
string includes the prompt as well, so you get e.g.

AB8500_DEBUG "Enable debug info via debugfs"

Those strings are then searched/displayed.

What you got with your search was all symbols whose names end in
"_DEBUG" that don't have a prompt.

The nice thing about searching both the name and the prompt is that
e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
add menus to the search, by generating 'menu: "menu title"' strings
for them.

It's a bit awkward/unintuitive that what you tried doesn't work
though. Maybe the symbol name could be searched separately from the
prompt, though I'd be a bit sad to abandon the super simple
single-string-per-entry implementation approach. :)

Thanks,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap  wrote:
> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> I've added incremental search for jumping directly to a symbol now.
>>> Regular expressions are supported as well.
>>>
>>> Some screenshots below:
>>>
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>
>>> The last screenshot shows how things might look after you jump to a
>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>> mode was turned on automatically.
>>
>> Hi Ulf,
>>
>>
>>
>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
>> now.
>>
>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>> Kconfiglib/menuconfig.py
>>
>> so yes, a real Makefile target would be nice. :)
>
> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
> _DEBUGFS).  Using:
>
> /.*_DEBUG$
>
> shows me 6 symbols:
> ATH9K_COMMON_DEBUG
> DVB_B2C2_FLEXCOP_DEBUG
> HAVE_DMA_API_DEBUG
> IP_DCCP_TFRC_DEBUG
> NFS_DEBUG
> PM_SLEEP_DEBUG
>
> so where are the other (approx.) 176?
> see:
> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
> 182 3649179
>
>
> Anyway, something for you to look at. :)
>
> --
> ~Randy

It's related to how the search is done. Searching for "DEBUG\b" (word
boundary) instead will find all of them.

A string is generated for each symbol. For symbols with prompts, this
string includes the prompt as well, so you get e.g.

AB8500_DEBUG "Enable debug info via debugfs"

Those strings are then searched/displayed.

What you got with your search was all symbols whose names end in
"_DEBUG" that don't have a prompt.

The nice thing about searching both the name and the prompt is that
e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
add menus to the search, by generating 'menu: "menu title"' strings
for them.

It's a bit awkward/unintuitive that what you tried doesn't work
though. Maybe the symbol name could be searched separately from the
prompt, though I'd be a bit sad to abandon the super simple
single-string-per-entry implementation approach. :)

Thanks,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 5:51 AM, Randy Dunlap <rdun...@infradead.org> wrote:
> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> I've added incremental search for jumping directly to a symbol now.
>>> Regular expressions are supported as well.
>>>
>>> Some screenshots below:
>>>
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>
>>> The last screenshot shows how things might look after you jump to a
>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>> mode was turned on automatically.
>>
>> Hi Ulf,
>>
>>
>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
>> now.
>>
>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>> Kconfiglib/menuconfig.py
>>
>> so yes, a real Makefile target would be nice. :)
>
>
> Enter: / (search)
> then:  * (Bang) [this was just an unlucky typo on my part]
>
> Traceback (most recent call last):
>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in _jump_to_dialog
> for regex in s.split()]
>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in 
> for regex in s.split()]
>   File "/usr/lib64/python3.4/re.py", line 223, in compile
> return _compile(pattern, flags)
>   File "/usr/lib64/python3.4/re.py", line 294, in _compile
> p = sre_compile.compile(pattern, flags)
>   File "/usr/lib64/python3.4/sre_compile.py", line 568, in compile
> p = sre_parse.parse(p, flags)
>   File "/usr/lib64/python3.4/sre_parse.py", line 780, in parse
> p = _parse_sub(source, pattern, 0)
>   File "/usr/lib64/python3.4/sre_parse.py", line 377, in _parse_sub
> itemsappend(_parse(source, state))
>   File "/usr/lib64/python3.4/sre_parse.py", line 586, in _parse
> raise error("nothing to repeat")
> sre_constants.error: nothing to repeat
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/home/rdunlap/scripts/menuconfig.py", line 2389, in 
> menuconfig(Kconfig("Kconfig" if len(sys.argv) < 2 else sys.argv[1]))
>   File "/home/rdunlap/scripts/menuconfig.py", line 340, in menuconfig
> print(curses.wrapper(_menuconfig))
>   File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
> return func(stdscr, *args, **kwds)
>   File "/home/rdunlap/scripts/menuconfig.py", line 483, in _menuconfig
> _jump_to_dialog()
>   File "/home/rdunlap/scripts/menuconfig.py", line 1466, in _jump_to_dialog
> bad_re = e.msg
> AttributeError: 'error' object has no attribute 'msg'
>
>
>
> --
> ~Randy

Thanks for the report!

Invalid regular expressions are detected, but it looks like the 'msg'
field of re.error was added in Python 3.5 (you have 3.4).

I'll check if the 'msg' field exists and fall back to just printing
"Invalid regular expression" otherwise. The 'msg' field just gives a
more informative error
("Bad regular expression: nothing to repeat" in this case).

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 5:51 AM, Randy Dunlap  wrote:
> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> I've added incremental search for jumping directly to a symbol now.
>>> Regular expressions are supported as well.
>>>
>>> Some screenshots below:
>>>
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>
>>> The last screenshot shows how things might look after you jump to a
>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>> mode was turned on automatically.
>>
>> Hi Ulf,
>>
>>
>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
>> now.
>>
>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>> Kconfiglib/menuconfig.py
>>
>> so yes, a real Makefile target would be nice. :)
>
>
> Enter: / (search)
> then:  * (Bang) [this was just an unlucky typo on my part]
>
> Traceback (most recent call last):
>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in _jump_to_dialog
> for regex in s.split()]
>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in 
> for regex in s.split()]
>   File "/usr/lib64/python3.4/re.py", line 223, in compile
> return _compile(pattern, flags)
>   File "/usr/lib64/python3.4/re.py", line 294, in _compile
> p = sre_compile.compile(pattern, flags)
>   File "/usr/lib64/python3.4/sre_compile.py", line 568, in compile
> p = sre_parse.parse(p, flags)
>   File "/usr/lib64/python3.4/sre_parse.py", line 780, in parse
> p = _parse_sub(source, pattern, 0)
>   File "/usr/lib64/python3.4/sre_parse.py", line 377, in _parse_sub
> itemsappend(_parse(source, state))
>   File "/usr/lib64/python3.4/sre_parse.py", line 586, in _parse
> raise error("nothing to repeat")
> sre_constants.error: nothing to repeat
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/home/rdunlap/scripts/menuconfig.py", line 2389, in 
> menuconfig(Kconfig("Kconfig" if len(sys.argv) < 2 else sys.argv[1]))
>   File "/home/rdunlap/scripts/menuconfig.py", line 340, in menuconfig
> print(curses.wrapper(_menuconfig))
>   File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
> return func(stdscr, *args, **kwds)
>   File "/home/rdunlap/scripts/menuconfig.py", line 483, in _menuconfig
> _jump_to_dialog()
>   File "/home/rdunlap/scripts/menuconfig.py", line 1466, in _jump_to_dialog
> bad_re = e.msg
> AttributeError: 'error' object has no attribute 'msg'
>
>
>
> --
> ~Randy

Thanks for the report!

Invalid regular expressions are detected, but it looks like the 'msg'
field of re.error was added in Python 3.5 (you have 3.4).

I'll check if the 'msg' field exists and fall back to just printing
"Invalid regular expression" otherwise. The 'msg' field just gives a
more informative error
("Bad regular expression: nothing to repeat" in this case).

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Mon, May 14, 2018 at 6:58 PM, Pavel Machek  wrote:
> Hi!
>
>> > config CAN_PEAK_PCIEFD
>> > depends on PCI
>> > tristate "PEAK-System PCAN-PCIe FD cards"
>> > ---help---
>> >   This driver adds support for the PEAK-System PCI Express FD
>> >   CAN-FD cards family.
>> >   These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>> >   CAN-FD access to the CAN bus. Besides the nominal bitrate of up 
>> > to
>> >   1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>> >   up to 12 Mbit/s. A galvanic isolation of the CAN ports protects 
>> > the
>> >   electronics of the card and the respective computer against
>> >   disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>> >   operated with ambient temperatures in a range of -40 to +85 °C.
>> >
>> >
>> > kconfiglib.KconfigSyntaxError:
>> > Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>> > Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>> > Problematic data: b'\xc2'
>> > Reason: ordinal not in range(128)
>> >
>> >
>> > thanks,
>> > --
>> > ~Randy
>>
>> Thanks for trying it out!
>>
>> You're probably running in the C locale, which implies an ASCII
>> encoding. That has caused enough trouble that the Python devs decided
>> to automatically convert it to UTF-8 in Python 3.7:
>> https://www.python.org/dev/peps/pep-0538/. LC_CTYPE=C.UTF-8 should fix
>> it.
>>
>> It's a bit silly to have it crash for something like that though. I
>> could force UTF-8 instead of respecting the locale (though it feels
>> neater to respect settings), or tell Python to ignore decoding errors.
>> Should probably do something at least...
>
> Well, Kconfig files are utf-8, as is the rest of kernel.

Yeah, it's the only sane assumption anyway.

>
> So yes, you should respect $LC_CTYPE for display etc, but you should always
> assume Kconfig files are utf-8... and that does not need to be optional.

Already made it optional, with UTF-8 as the default (via
Kconfig.__init__(..., encoding="utf-8")).

I did a similar thing to what PEP 538 does for the menuconfig:
https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py#L2271.
The C locale is converted to a UTF-8 locale for LC_CTYPE if possible.
Other locales are respected. That'll be the default behavior in Python
3.7, and prevents issues with get_wch().

>
> Pavel

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Mon, May 14, 2018 at 6:58 PM, Pavel Machek  wrote:
> Hi!
>
>> > config CAN_PEAK_PCIEFD
>> > depends on PCI
>> > tristate "PEAK-System PCAN-PCIe FD cards"
>> > ---help---
>> >   This driver adds support for the PEAK-System PCI Express FD
>> >   CAN-FD cards family.
>> >   These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>> >   CAN-FD access to the CAN bus. Besides the nominal bitrate of up 
>> > to
>> >   1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>> >   up to 12 Mbit/s. A galvanic isolation of the CAN ports protects 
>> > the
>> >   electronics of the card and the respective computer against
>> >   disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>> >   operated with ambient temperatures in a range of -40 to +85 °C.
>> >
>> >
>> > kconfiglib.KconfigSyntaxError:
>> > Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>> > Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>> > Problematic data: b'\xc2'
>> > Reason: ordinal not in range(128)
>> >
>> >
>> > thanks,
>> > --
>> > ~Randy
>>
>> Thanks for trying it out!
>>
>> You're probably running in the C locale, which implies an ASCII
>> encoding. That has caused enough trouble that the Python devs decided
>> to automatically convert it to UTF-8 in Python 3.7:
>> https://www.python.org/dev/peps/pep-0538/. LC_CTYPE=C.UTF-8 should fix
>> it.
>>
>> It's a bit silly to have it crash for something like that though. I
>> could force UTF-8 instead of respecting the locale (though it feels
>> neater to respect settings), or tell Python to ignore decoding errors.
>> Should probably do something at least...
>
> Well, Kconfig files are utf-8, as is the rest of kernel.

Yeah, it's the only sane assumption anyway.

>
> So yes, you should respect $LC_CTYPE for display etc, but you should always
> assume Kconfig files are utf-8... and that does not need to be optional.

Already made it optional, with UTF-8 as the default (via
Kconfig.__init__(..., encoding="utf-8")).

I did a similar thing to what PEP 538 does for the menuconfig:
https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py#L2271.
The C locale is converted to a UTF-8 locale for LC_CTYPE if possible.
Other locales are respected. That'll be the default behavior in Python
3.7, and prevents issues with get_wch().

>
> Pavel

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 8, 2018 at 6:59 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> Hello,
>
> I've added incremental search for jumping directly to a symbol now.
> Regular expressions are supported as well.
>
> Some screenshots below:
>
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>
> The last screenshot shows how things might look after you jump to a
> symbol. The jumped-to symbol wasn't visible in this case, so show-all
> mode was turned on automatically.
>

Some new search-related features:

  - The jump-to dialog now searches and lists prompt texts.

  - A kind of poor man's fuzzy search has been added. 'foo bar baz'
matches all entries that match all of 'foo', 'bar', and 'baz', as
regexes.

Demo: https://asciinema.org/a/Q4UNFVPF5zd62KqjrG95mowkG

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 8, 2018 at 6:59 PM, Ulf Magnusson  wrote:
> Hello,
>
> I've added incremental search for jumping directly to a symbol now.
> Regular expressions are supported as well.
>
> Some screenshots below:
>
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>
> The last screenshot shows how things might look after you jump to a
> symbol. The jumped-to symbol wasn't visible in this case, so show-all
> mode was turned on automatically.
>

Some new search-related features:

  - The jump-to dialog now searches and lists prompt texts.

  - A kind of poor man's fuzzy search has been added. 'foo bar baz'
matches all entries that match all of 'foo', 'bar', and 'baz', as
regexes.

Demo: https://asciinema.org/a/Q4UNFVPF5zd62KqjrG95mowkG

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

Hello,

I've added incremental search for jumping directly to a symbol now.
Regular expressions are supported as well.

Some screenshots below:

https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png

The last screenshot shows how things might look after you jump to a
symbol. The jumped-to symbol wasn't visible in this case, so show-all
mode was turned on automatically.

On Thu, May 3, 2018 at 10:28 PM, Randy Dunlap  wrote:
> Hi,
>
> (with new kconfiglib.py and menuconfig.py)
>
> Thanks for the fixes.
>
> If I use "LC_CTYPE=C.UTF-8" then I get the down arrows in the bottom colored
> bar.  Without that, I get an upside-down T (that is 193, 0xc1, line drawing
> character in the IBM extended character set).

It now automatically tries to convert LC_CTYPE to a UTF-8 locale if it
is set to the C locale, similar to what PEP 538 does. I took the list
of locales to try from the CPython implementation.

That will save a bunch of pain in practice.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

Hello,

I've added incremental search for jumping directly to a symbol now.
Regular expressions are supported as well.

Some screenshots below:

https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png

The last screenshot shows how things might look after you jump to a
symbol. The jumped-to symbol wasn't visible in this case, so show-all
mode was turned on automatically.

On Thu, May 3, 2018 at 10:28 PM, Randy Dunlap  wrote:
> Hi,
>
> (with new kconfiglib.py and menuconfig.py)
>
> Thanks for the fixes.
>
> If I use "LC_CTYPE=C.UTF-8" then I get the down arrows in the bottom colored
> bar.  Without that, I get an upside-down T (that is 193, 0xc1, line drawing
> character in the IBM extended character set).

It now automatically tries to convert LC_CTYPE to a UTF-8 locale if it
is set to the C locale, similar to what PEP 538 does. I took the list
of locales to try from the CPython implementation.

That will save a bunch of pain in practice.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Thu, May 3, 2018 at 10:28 PM, Randy Dunlap  wrote:
> Hi,
>
> (with new kconfiglib.py and menuconfig.py)
>
> Thanks for the fixes.
>
> If I use "LC_CTYPE=C.UTF-8" then I get the down arrows in the bottom colored
> bar.  Without that, I get an upside-down T (that is 193, 0xc1, line drawing
> character in the IBM extended character set).
>
> Hm. With LC_CTYPE=C.UTF-8, the upper colored bar prints up arrows.
> Without that, it prints ^^.
> That's nice that it can do either.

The arrows use ACS_U/DARROW from the alternate character set. You get
nice Unicode arrows for those with ncurses/PDCurses, plus "fallbacks"
(strictly speaking the Unicode arrows are fallbacks too).

Unicode text entry is still broken with LC_CTYPE=C, because ncurses
respects it. Having the menuconfig just force C.UTF-8 if it's
available might fix a bunch of problems in practice, even if it feels
a bit iffy to force settings.

Python 3.7 will improve things at least. It converts LC_CTYPE=C into
LC_CTYPE=.

Cleanest would be if all environments sanely defaulted to UTF-8, but
that's not how it is in practice, unfortunately. :)

>
> Being a vim user, I do like the optional navigation keys.
>
> --
> ~Randy

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Thu, May 3, 2018 at 10:28 PM, Randy Dunlap  wrote:
> Hi,
>
> (with new kconfiglib.py and menuconfig.py)
>
> Thanks for the fixes.
>
> If I use "LC_CTYPE=C.UTF-8" then I get the down arrows in the bottom colored
> bar.  Without that, I get an upside-down T (that is 193, 0xc1, line drawing
> character in the IBM extended character set).
>
> Hm. With LC_CTYPE=C.UTF-8, the upper colored bar prints up arrows.
> Without that, it prints ^^.
> That's nice that it can do either.

The arrows use ACS_U/DARROW from the alternate character set. You get
nice Unicode arrows for those with ncurses/PDCurses, plus "fallbacks"
(strictly speaking the Unicode arrows are fallbacks too).

Unicode text entry is still broken with LC_CTYPE=C, because ncurses
respects it. Having the menuconfig just force C.UTF-8 if it's
available might fix a bunch of problems in practice, even if it feels
a bit iffy to force settings.

Python 3.7 will improve things at least. It converts LC_CTYPE=C into
LC_CTYPE=.

Cleanest would be if all environments sanely defaulted to UTF-8, but
that's not how it is in practice, unfortunately. :)

>
> Being a vim user, I do like the optional navigation keys.
>
> --
> ~Randy

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Thu, May 3, 2018 at 10:31 PM, Randy Dunlap  wrote:
> One minor nit (bikeshed?):  I'm not crazy about "make scriptconfig".  :)
>
> thanks,
> --
> ~Randy

To be honest, I just do

ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
Kconfiglib/menuconfig.py

Should probably add a target to the makefile patch. Need to pick up
environment variables somehow.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Thu, May 3, 2018 at 10:31 PM, Randy Dunlap  wrote:
> One minor nit (bikeshed?):  I'm not crazy about "make scriptconfig".  :)
>
> thanks,
> --
> ~Randy

To be honest, I just do

ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
Kconfiglib/menuconfig.py

Should probably add a target to the makefile patch. Need to pick up
environment variables somehow.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 1, 2018 at 8:52 PM, Randy Dunlap <rdun...@infradead.org> wrote:
> On 05/01/2018 11:13 AM, Randy Dunlap wrote:
>> On 05/01/2018 10:56 AM, Randy Dunlap wrote:
>>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>>>> terminal menuconfig implementation, implemented in plain curses
>>>> (which is in the Python standard library).
>>>>
>>>> The interface should feel familiar to people used to mconf. It has
>>>> some features that mconf lacks:
>>>>
>>>>   - Seamless resizing
>>>>
>>>>   - Unicode support
>>>>
>>>>   - Runs on Windows (via 'pip install windows-curses', which uses
>>>> PDCurses)
>>>>
>>>>   - Improved information displays:
>>>>
>>>> * All expressions are split into readable chunks
>>>>
>>>> * Menus and comments have information displays
>>>>
>>>>   - Relatively easy-to-read and easy-to-tweak code.
>>>>
>>>> Kconfiglib automatically invalidates symbols as needed, and
>>>> values can never get stale, which helps.
>>>>
>>>> Some upcoming features are mouse support and a search feature that
>>>> can jump directly to the definition of a symbol. The jump-to feature
>>>> will use a "show-all" mode in case the symbol isn't visible.
>>>>
>>>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>>>> implementation is at
>>>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>>>> The docstring at the top has some more information.
>>>
>>> Hi,
>>>
>>> I'm probably missing some python additive (I hope it's that easy), but
>>> menuconfig.py is not liking the "degree" symbol in 
>>> drivers/net/can/peak_canfd/Kconfig:
>>>
>>> config CAN_PEAK_PCIEFD
>>>  depends on PCI
>>>  tristate "PEAK-System PCAN-PCIe FD cards"
>>>  ---help---
>>>This driver adds support for the PEAK-System PCI Express FD
>>>CAN-FD cards family.
>>>These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>>>CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>>>1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>>>up to 12 Mbit/s. A galvanic isolation of the CAN ports protects the
>>>electronics of the card and the respective computer against
>>>disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>>>operated with ambient temperatures in a range of -40 to +85 °C.
>>>
>>>
>>> kconfiglib.KconfigSyntaxError:
>>> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>>> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>>> Problematic data: b'\xc2'
>>> Reason: ordinal not in range(128)
>>
>> BTW, after modifying 4 other instances of this "error," I have it running.
>> Now looking/testing. :)
>
> Hi Ulf,
>
> Here are a few comments for you FWIW.
>
> menuconfig.py uses the terminal window space better than menuconfig:
> fewer margins, less Help text so more usable lines.
>
> ESC/q is nicer than in ESC+ESC in menuconfig.
>
> What is the lower colored line for? I don't see it being used.

It might show "Show-all mode enabled" now too. ;)

>
> On Quit, don't need to prompt for Save when the file is already saved
> or has not been modified.

Fixed.

>
> When menuconfig displays the Kconfig menu tree and it is over term-width
> characters, it truncates on the left so that the user can see all of
> the current menu name. menuconfig.py truncates on the right so that
> the current menu name may be partially lost or totally lost.

Fixed. The menu path now scrolls to the right as needed. Maybe "..."
could be displayed as well, though I'm not sure if it's helpful in
practice.

>
> To enable=y a tristate symbol, cannot enter Y, must do Space Space to cycle
> from N to M to Y.

Fixed.

>
> No / symbol search. I use that a lot, but I don't claim to be a
> typical user.

Coming soon. I have added a "show-all" mode in preparation for it, as
you might want to jump to invisible symbols.

Screenshot: 
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss9.png

>
>
> Thanks.
> --
> ~Randy

Thanks for the feedback! Tell me if you spot anything else.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 1, 2018 at 8:52 PM, Randy Dunlap  wrote:
> On 05/01/2018 11:13 AM, Randy Dunlap wrote:
>> On 05/01/2018 10:56 AM, Randy Dunlap wrote:
>>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>>>> terminal menuconfig implementation, implemented in plain curses
>>>> (which is in the Python standard library).
>>>>
>>>> The interface should feel familiar to people used to mconf. It has
>>>> some features that mconf lacks:
>>>>
>>>>   - Seamless resizing
>>>>
>>>>   - Unicode support
>>>>
>>>>   - Runs on Windows (via 'pip install windows-curses', which uses
>>>> PDCurses)
>>>>
>>>>   - Improved information displays:
>>>>
>>>> * All expressions are split into readable chunks
>>>>
>>>> * Menus and comments have information displays
>>>>
>>>>   - Relatively easy-to-read and easy-to-tweak code.
>>>>
>>>> Kconfiglib automatically invalidates symbols as needed, and
>>>> values can never get stale, which helps.
>>>>
>>>> Some upcoming features are mouse support and a search feature that
>>>> can jump directly to the definition of a symbol. The jump-to feature
>>>> will use a "show-all" mode in case the symbol isn't visible.
>>>>
>>>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>>>> implementation is at
>>>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>>>> The docstring at the top has some more information.
>>>
>>> Hi,
>>>
>>> I'm probably missing some python additive (I hope it's that easy), but
>>> menuconfig.py is not liking the "degree" symbol in 
>>> drivers/net/can/peak_canfd/Kconfig:
>>>
>>> config CAN_PEAK_PCIEFD
>>>  depends on PCI
>>>  tristate "PEAK-System PCAN-PCIe FD cards"
>>>  ---help---
>>>This driver adds support for the PEAK-System PCI Express FD
>>>CAN-FD cards family.
>>>These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>>>CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>>>1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>>>up to 12 Mbit/s. A galvanic isolation of the CAN ports protects the
>>>electronics of the card and the respective computer against
>>>disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>>>operated with ambient temperatures in a range of -40 to +85 °C.
>>>
>>>
>>> kconfiglib.KconfigSyntaxError:
>>> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>>> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>>> Problematic data: b'\xc2'
>>> Reason: ordinal not in range(128)
>>
>> BTW, after modifying 4 other instances of this "error," I have it running.
>> Now looking/testing. :)
>
> Hi Ulf,
>
> Here are a few comments for you FWIW.
>
> menuconfig.py uses the terminal window space better than menuconfig:
> fewer margins, less Help text so more usable lines.
>
> ESC/q is nicer than in ESC+ESC in menuconfig.
>
> What is the lower colored line for? I don't see it being used.

It might show "Show-all mode enabled" now too. ;)

>
> On Quit, don't need to prompt for Save when the file is already saved
> or has not been modified.

Fixed.

>
> When menuconfig displays the Kconfig menu tree and it is over term-width
> characters, it truncates on the left so that the user can see all of
> the current menu name. menuconfig.py truncates on the right so that
> the current menu name may be partially lost or totally lost.

Fixed. The menu path now scrolls to the right as needed. Maybe "..."
could be displayed as well, though I'm not sure if it's helpful in
practice.

>
> To enable=y a tristate symbol, cannot enter Y, must do Space Space to cycle
> from N to M to Y.

Fixed.

>
> No / symbol search. I use that a lot, but I don't claim to be a
> typical user.

Coming soon. I have added a "show-all" mode in preparation for it, as
you might want to jump to invisible symbols.

Screenshot: 
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss9.png

>
>
> Thanks.
> --
> ~Randy

Thanks for the feedback! Tell me if you spot anything else.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 1, 2018 at 9:47 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Tue, May 1, 2018 at 9:12 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
>> On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap <rdun...@infradead.org> wrote:
>>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>>>> terminal menuconfig implementation, implemented in plain curses
>>>> (which is in the Python standard library).
>>>>
>>>> The interface should feel familiar to people used to mconf. It has
>>>> some features that mconf lacks:
>>>>
>>>>   - Seamless resizing
>>>>
>>>>   - Unicode support
>>>>
>>>>   - Runs on Windows (via 'pip install windows-curses', which uses
>>>> PDCurses)
>>>>
>>>>   - Improved information displays:
>>>>
>>>> * All expressions are split into readable chunks
>>>>
>>>> * Menus and comments have information displays
>>>>
>>>>   - Relatively easy-to-read and easy-to-tweak code.
>>>>
>>>> Kconfiglib automatically invalidates symbols as needed, and
>>>> values can never get stale, which helps.
>>>>
>>>> Some upcoming features are mouse support and a search feature that
>>>> can jump directly to the definition of a symbol. The jump-to feature
>>>> will use a "show-all" mode in case the symbol isn't visible.
>>>>
>>>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>>>> implementation is at
>>>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>>>> The docstring at the top has some more information.
>>>
>>> Hi,
>>>
>>> I'm probably missing some python additive (I hope it's that easy), but
>>> menuconfig.py is not liking the "degree" symbol in 
>>> drivers/net/can/peak_canfd/Kconfig:
>>>
>>> config CAN_PEAK_PCIEFD
>>> depends on PCI
>>> tristate "PEAK-System PCAN-PCIe FD cards"
>>> ---help---
>>>   This driver adds support for the PEAK-System PCI Express FD
>>>   CAN-FD cards family.
>>>   These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>>>   CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>>>   1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>>>   up to 12 Mbit/s. A galvanic isolation of the CAN ports protects 
>>> the
>>>   electronics of the card and the respective computer against
>>>   disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>>>   operated with ambient temperatures in a range of -40 to +85 °C.
>>>
>>>
>>> kconfiglib.KconfigSyntaxError:
>>> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>>> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>>> Problematic data: b'\xc2'
>>> Reason: ordinal not in range(128)
>>>
>>>
>>> thanks,
>>> --
>>> ~Randy
>>
>> Thanks for trying it out!
>>
>> You're probably running in the C locale, which implies an ASCII
>> encoding. That has caused enough trouble that the Python devs decided
>> to automatically convert it to UTF-8 in Python 3.7:
>> https://www.python.org/dev/peps/pep-0538/. LC_CTYPE=C.UTF-8 should fix
>> it.
>>
>> It's a bit silly to have it crash for something like that though. I
>> could force UTF-8 instead of respecting the locale (though it feels
>> neater to respect settings), or tell Python to ignore decoding errors.
>> Should probably do something at least...
>>
>> Cheers,
>> Ulf
>
> Leaning towards just forcing UTF-8. It's what you want in 99% of
> cases, and ignoring decoding errors would be unsafe for Unicode string
> values.
>
> Could make the forcing optional, and default to on...
>
> Cheers,
> Ulf

Went with a more general solution:
https://github.com/ulfalizer/Kconfiglib/commit/da40c014398f329b324a2eb9de062344e773dc74

You can now specify any encoding (or None, to use the encoding
specified in the environment), with "utf-8" as the default. That
default probably saves a bunch of pain in practice.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 1, 2018 at 9:47 PM, Ulf Magnusson  wrote:
> On Tue, May 1, 2018 at 9:12 PM, Ulf Magnusson  wrote:
>> On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap  wrote:
>>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>>>> terminal menuconfig implementation, implemented in plain curses
>>>> (which is in the Python standard library).
>>>>
>>>> The interface should feel familiar to people used to mconf. It has
>>>> some features that mconf lacks:
>>>>
>>>>   - Seamless resizing
>>>>
>>>>   - Unicode support
>>>>
>>>>   - Runs on Windows (via 'pip install windows-curses', which uses
>>>> PDCurses)
>>>>
>>>>   - Improved information displays:
>>>>
>>>> * All expressions are split into readable chunks
>>>>
>>>> * Menus and comments have information displays
>>>>
>>>>   - Relatively easy-to-read and easy-to-tweak code.
>>>>
>>>> Kconfiglib automatically invalidates symbols as needed, and
>>>> values can never get stale, which helps.
>>>>
>>>> Some upcoming features are mouse support and a search feature that
>>>> can jump directly to the definition of a symbol. The jump-to feature
>>>> will use a "show-all" mode in case the symbol isn't visible.
>>>>
>>>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>>>> implementation is at
>>>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>>>> The docstring at the top has some more information.
>>>
>>> Hi,
>>>
>>> I'm probably missing some python additive (I hope it's that easy), but
>>> menuconfig.py is not liking the "degree" symbol in 
>>> drivers/net/can/peak_canfd/Kconfig:
>>>
>>> config CAN_PEAK_PCIEFD
>>> depends on PCI
>>> tristate "PEAK-System PCAN-PCIe FD cards"
>>> ---help---
>>>   This driver adds support for the PEAK-System PCI Express FD
>>>   CAN-FD cards family.
>>>   These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>>>   CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>>>   1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>>>   up to 12 Mbit/s. A galvanic isolation of the CAN ports protects 
>>> the
>>>   electronics of the card and the respective computer against
>>>   disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>>>   operated with ambient temperatures in a range of -40 to +85 °C.
>>>
>>>
>>> kconfiglib.KconfigSyntaxError:
>>> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>>> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>>> Problematic data: b'\xc2'
>>> Reason: ordinal not in range(128)
>>>
>>>
>>> thanks,
>>> --
>>> ~Randy
>>
>> Thanks for trying it out!
>>
>> You're probably running in the C locale, which implies an ASCII
>> encoding. That has caused enough trouble that the Python devs decided
>> to automatically convert it to UTF-8 in Python 3.7:
>> https://www.python.org/dev/peps/pep-0538/. LC_CTYPE=C.UTF-8 should fix
>> it.
>>
>> It's a bit silly to have it crash for something like that though. I
>> could force UTF-8 instead of respecting the locale (though it feels
>> neater to respect settings), or tell Python to ignore decoding errors.
>> Should probably do something at least...
>>
>> Cheers,
>> Ulf
>
> Leaning towards just forcing UTF-8. It's what you want in 99% of
> cases, and ignoring decoding errors would be unsafe for Unicode string
> values.
>
> Could make the forcing optional, and default to on...
>
> Cheers,
> Ulf

Went with a more general solution:
https://github.com/ulfalizer/Kconfiglib/commit/da40c014398f329b324a2eb9de062344e773dc74

You can now specify any encoding (or None, to use the encoding
specified in the environment), with "utf-8" as the default. That
default probably saves a bunch of pain in practice.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 1, 2018 at 9:12 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap <rdun...@infradead.org> wrote:
>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>>> terminal menuconfig implementation, implemented in plain curses
>>> (which is in the Python standard library).
>>>
>>> The interface should feel familiar to people used to mconf. It has
>>> some features that mconf lacks:
>>>
>>>   - Seamless resizing
>>>
>>>   - Unicode support
>>>
>>>   - Runs on Windows (via 'pip install windows-curses', which uses
>>> PDCurses)
>>>
>>>   - Improved information displays:
>>>
>>> * All expressions are split into readable chunks
>>>
>>> * Menus and comments have information displays
>>>
>>>   - Relatively easy-to-read and easy-to-tweak code.
>>>
>>> Kconfiglib automatically invalidates symbols as needed, and
>>> values can never get stale, which helps.
>>>
>>> Some upcoming features are mouse support and a search feature that
>>> can jump directly to the definition of a symbol. The jump-to feature
>>> will use a "show-all" mode in case the symbol isn't visible.
>>>
>>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>>> implementation is at
>>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>>> The docstring at the top has some more information.
>>
>> Hi,
>>
>> I'm probably missing some python additive (I hope it's that easy), but
>> menuconfig.py is not liking the "degree" symbol in 
>> drivers/net/can/peak_canfd/Kconfig:
>>
>> config CAN_PEAK_PCIEFD
>> depends on PCI
>> tristate "PEAK-System PCAN-PCIe FD cards"
>> ---help---
>>   This driver adds support for the PEAK-System PCI Express FD
>>   CAN-FD cards family.
>>   These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>>   CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>>   1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>>   up to 12 Mbit/s. A galvanic isolation of the CAN ports protects the
>>   electronics of the card and the respective computer against
>>   disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>>   operated with ambient temperatures in a range of -40 to +85 °C.
>>
>>
>> kconfiglib.KconfigSyntaxError:
>> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>> Problematic data: b'\xc2'
>> Reason: ordinal not in range(128)
>>
>>
>> thanks,
>> --
>> ~Randy
>
> Thanks for trying it out!
>
> You're probably running in the C locale, which implies an ASCII
> encoding. That has caused enough trouble that the Python devs decided
> to automatically convert it to UTF-8 in Python 3.7:
> https://www.python.org/dev/peps/pep-0538/. LC_CTYPE=C.UTF-8 should fix
> it.
>
> It's a bit silly to have it crash for something like that though. I
> could force UTF-8 instead of respecting the locale (though it feels
> neater to respect settings), or tell Python to ignore decoding errors.
> Should probably do something at least...
>
> Cheers,
> Ulf

Leaning towards just forcing UTF-8. It's what you want in 99% of
cases, and ignoring decoding errors would be unsafe for Unicode string
values.

Could make the forcing optional, and default to on...

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 1, 2018 at 9:12 PM, Ulf Magnusson  wrote:
> On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap  wrote:
>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>>> terminal menuconfig implementation, implemented in plain curses
>>> (which is in the Python standard library).
>>>
>>> The interface should feel familiar to people used to mconf. It has
>>> some features that mconf lacks:
>>>
>>>   - Seamless resizing
>>>
>>>   - Unicode support
>>>
>>>   - Runs on Windows (via 'pip install windows-curses', which uses
>>> PDCurses)
>>>
>>>   - Improved information displays:
>>>
>>> * All expressions are split into readable chunks
>>>
>>> * Menus and comments have information displays
>>>
>>>   - Relatively easy-to-read and easy-to-tweak code.
>>>
>>> Kconfiglib automatically invalidates symbols as needed, and
>>> values can never get stale, which helps.
>>>
>>> Some upcoming features are mouse support and a search feature that
>>> can jump directly to the definition of a symbol. The jump-to feature
>>> will use a "show-all" mode in case the symbol isn't visible.
>>>
>>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>>> implementation is at
>>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>>> The docstring at the top has some more information.
>>
>> Hi,
>>
>> I'm probably missing some python additive (I hope it's that easy), but
>> menuconfig.py is not liking the "degree" symbol in 
>> drivers/net/can/peak_canfd/Kconfig:
>>
>> config CAN_PEAK_PCIEFD
>> depends on PCI
>> tristate "PEAK-System PCAN-PCIe FD cards"
>> ---help---
>>   This driver adds support for the PEAK-System PCI Express FD
>>   CAN-FD cards family.
>>   These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>>   CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>>   1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>>   up to 12 Mbit/s. A galvanic isolation of the CAN ports protects the
>>   electronics of the card and the respective computer against
>>   disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>>   operated with ambient temperatures in a range of -40 to +85 °C.
>>
>>
>> kconfiglib.KconfigSyntaxError:
>> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>> Problematic data: b'\xc2'
>> Reason: ordinal not in range(128)
>>
>>
>> thanks,
>> --
>> ~Randy
>
> Thanks for trying it out!
>
> You're probably running in the C locale, which implies an ASCII
> encoding. That has caused enough trouble that the Python devs decided
> to automatically convert it to UTF-8 in Python 3.7:
> https://www.python.org/dev/peps/pep-0538/. LC_CTYPE=C.UTF-8 should fix
> it.
>
> It's a bit silly to have it crash for something like that though. I
> could force UTF-8 instead of respecting the locale (though it feels
> neater to respect settings), or tell Python to ignore decoding errors.
> Should probably do something at least...
>
> Cheers,
> Ulf

Leaning towards just forcing UTF-8. It's what you want in 99% of
cases, and ignoring decoding errors would be unsafe for Unicode string
values.

Could make the forcing optional, and default to on...

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 1, 2018 at 8:52 PM, Randy Dunlap <rdun...@infradead.org> wrote:
> On 05/01/2018 11:13 AM, Randy Dunlap wrote:
>> On 05/01/2018 10:56 AM, Randy Dunlap wrote:
>>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>>>> terminal menuconfig implementation, implemented in plain curses
>>>> (which is in the Python standard library).
>>>>
>>>> The interface should feel familiar to people used to mconf. It has
>>>> some features that mconf lacks:
>>>>
>>>>   - Seamless resizing
>>>>
>>>>   - Unicode support
>>>>
>>>>   - Runs on Windows (via 'pip install windows-curses', which uses
>>>> PDCurses)
>>>>
>>>>   - Improved information displays:
>>>>
>>>> * All expressions are split into readable chunks
>>>>
>>>> * Menus and comments have information displays
>>>>
>>>>   - Relatively easy-to-read and easy-to-tweak code.
>>>>
>>>> Kconfiglib automatically invalidates symbols as needed, and
>>>> values can never get stale, which helps.
>>>>
>>>> Some upcoming features are mouse support and a search feature that
>>>> can jump directly to the definition of a symbol. The jump-to feature
>>>> will use a "show-all" mode in case the symbol isn't visible.
>>>>
>>>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>>>> implementation is at
>>>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>>>> The docstring at the top has some more information.
>>>
>>> Hi,
>>>
>>> I'm probably missing some python additive (I hope it's that easy), but
>>> menuconfig.py is not liking the "degree" symbol in 
>>> drivers/net/can/peak_canfd/Kconfig:
>>>
>>> config CAN_PEAK_PCIEFD
>>>  depends on PCI
>>>  tristate "PEAK-System PCAN-PCIe FD cards"
>>>  ---help---
>>>This driver adds support for the PEAK-System PCI Express FD
>>>CAN-FD cards family.
>>>These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>>>CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>>>1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>>>up to 12 Mbit/s. A galvanic isolation of the CAN ports protects the
>>>electronics of the card and the respective computer against
>>>disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>>>operated with ambient temperatures in a range of -40 to +85 °C.
>>>
>>>
>>> kconfiglib.KconfigSyntaxError:
>>> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>>> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>>> Problematic data: b'\xc2'
>>> Reason: ordinal not in range(128)
>>
>> BTW, after modifying 4 other instances of this "error," I have it running.
>> Now looking/testing. :)
>
> Hi Ulf,
>
> Here are a few comments for you FWIW.
>
> menuconfig.py uses the terminal window space better than menuconfig:
> fewer margins, less Help text so more usable lines.
>
> ESC/q is nicer than in ESC+ESC in menuconfig.
>
> What is the lower colored line for? I don't see it being used.

It's just a separator above the help text with the keys. Also has
arrows pointing down when the window is scrolled up.

Maybe the help text could appear directly at the bottom with a
different background color instead. Not sure if it'd get uglier.

>
> On Quit, don't need to prompt for Save when the file is already saved
> or has not been modified.

Will fix. I had gotten the idea that mconf always prompted, so I got
lazy for the initial version. :)

>
> When menuconfig displays the Kconfig menu tree and it is over term-width
> characters, it truncates on the left so that the user can see all of
> the current menu name. menuconfig.py truncates on the right so that
> the current menu name may be partially lost or totally lost.

You mean the menu path at the top? Will fix that.

>
> To enable=y a tristate symbol, cannot enter Y, must do Space Space to cycle
> from N to M to Y.

Had never noticed that feature in mconf. I'll add it.

>
> No / symbol search. I use that a lot, but I don't claim to be a
> typical user.

It's planned. It will also support jumping directly to a symbol in the
menu tree, which is a feature I've always missed in mconf.

A "show all" mode will be added at the same time, that shows invisible
symbols. Jumping to an invisible symbol can then turn it in
automatically.

>
>
> Thanks.
> --
> ~Randy

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 1, 2018 at 8:52 PM, Randy Dunlap  wrote:
> On 05/01/2018 11:13 AM, Randy Dunlap wrote:
>> On 05/01/2018 10:56 AM, Randy Dunlap wrote:
>>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>>>> terminal menuconfig implementation, implemented in plain curses
>>>> (which is in the Python standard library).
>>>>
>>>> The interface should feel familiar to people used to mconf. It has
>>>> some features that mconf lacks:
>>>>
>>>>   - Seamless resizing
>>>>
>>>>   - Unicode support
>>>>
>>>>   - Runs on Windows (via 'pip install windows-curses', which uses
>>>> PDCurses)
>>>>
>>>>   - Improved information displays:
>>>>
>>>> * All expressions are split into readable chunks
>>>>
>>>> * Menus and comments have information displays
>>>>
>>>>   - Relatively easy-to-read and easy-to-tweak code.
>>>>
>>>> Kconfiglib automatically invalidates symbols as needed, and
>>>> values can never get stale, which helps.
>>>>
>>>> Some upcoming features are mouse support and a search feature that
>>>> can jump directly to the definition of a symbol. The jump-to feature
>>>> will use a "show-all" mode in case the symbol isn't visible.
>>>>
>>>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>>>> implementation is at
>>>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>>>> The docstring at the top has some more information.
>>>
>>> Hi,
>>>
>>> I'm probably missing some python additive (I hope it's that easy), but
>>> menuconfig.py is not liking the "degree" symbol in 
>>> drivers/net/can/peak_canfd/Kconfig:
>>>
>>> config CAN_PEAK_PCIEFD
>>>  depends on PCI
>>>  tristate "PEAK-System PCAN-PCIe FD cards"
>>>  ---help---
>>>This driver adds support for the PEAK-System PCI Express FD
>>>CAN-FD cards family.
>>>These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>>>CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>>>1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>>>up to 12 Mbit/s. A galvanic isolation of the CAN ports protects the
>>>electronics of the card and the respective computer against
>>>disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>>>operated with ambient temperatures in a range of -40 to +85 °C.
>>>
>>>
>>> kconfiglib.KconfigSyntaxError:
>>> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>>> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>>> Problematic data: b'\xc2'
>>> Reason: ordinal not in range(128)
>>
>> BTW, after modifying 4 other instances of this "error," I have it running.
>> Now looking/testing. :)
>
> Hi Ulf,
>
> Here are a few comments for you FWIW.
>
> menuconfig.py uses the terminal window space better than menuconfig:
> fewer margins, less Help text so more usable lines.
>
> ESC/q is nicer than in ESC+ESC in menuconfig.
>
> What is the lower colored line for? I don't see it being used.

It's just a separator above the help text with the keys. Also has
arrows pointing down when the window is scrolled up.

Maybe the help text could appear directly at the bottom with a
different background color instead. Not sure if it'd get uglier.

>
> On Quit, don't need to prompt for Save when the file is already saved
> or has not been modified.

Will fix. I had gotten the idea that mconf always prompted, so I got
lazy for the initial version. :)

>
> When menuconfig displays the Kconfig menu tree and it is over term-width
> characters, it truncates on the left so that the user can see all of
> the current menu name. menuconfig.py truncates on the right so that
> the current menu name may be partially lost or totally lost.

You mean the menu path at the top? Will fix that.

>
> To enable=y a tristate symbol, cannot enter Y, must do Space Space to cycle
> from N to M to Y.

Had never noticed that feature in mconf. I'll add it.

>
> No / symbol search. I use that a lot, but I don't claim to be a
> typical user.

It's planned. It will also support jumping directly to a symbol in the
menu tree, which is a feature I've always missed in mconf.

A "show all" mode will be added at the same time, that shows invisible
symbols. Jumping to an invisible symbol can then turn it in
automatically.

>
>
> Thanks.
> --
> ~Randy

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap <rdun...@infradead.org> wrote:
> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>> Hello,
>>
>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>> terminal menuconfig implementation, implemented in plain curses
>> (which is in the Python standard library).
>>
>> The interface should feel familiar to people used to mconf. It has
>> some features that mconf lacks:
>>
>>   - Seamless resizing
>>
>>   - Unicode support
>>
>>   - Runs on Windows (via 'pip install windows-curses', which uses
>> PDCurses)
>>
>>   - Improved information displays:
>>
>> * All expressions are split into readable chunks
>>
>> * Menus and comments have information displays
>>
>>   - Relatively easy-to-read and easy-to-tweak code.
>>
>> Kconfiglib automatically invalidates symbols as needed, and
>> values can never get stale, which helps.
>>
>> Some upcoming features are mouse support and a search feature that
>> can jump directly to the definition of a symbol. The jump-to feature
>> will use a "show-all" mode in case the symbol isn't visible.
>>
>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>> implementation is at
>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>> The docstring at the top has some more information.
>
> Hi,
>
> I'm probably missing some python additive (I hope it's that easy), but
> menuconfig.py is not liking the "degree" symbol in 
> drivers/net/can/peak_canfd/Kconfig:
>
> config CAN_PEAK_PCIEFD
> depends on PCI
> tristate "PEAK-System PCAN-PCIe FD cards"
> ---help---
>   This driver adds support for the PEAK-System PCI Express FD
>   CAN-FD cards family.
>   These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>   CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>   1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>   up to 12 Mbit/s. A galvanic isolation of the CAN ports protects the
>   electronics of the card and the respective computer against
>   disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>   operated with ambient temperatures in a range of -40 to +85 °C.
>
>
> kconfiglib.KconfigSyntaxError:
> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
> Problematic data: b'\xc2'
> Reason: ordinal not in range(128)
>
>
> thanks,
> --
> ~Randy

Thanks for trying it out!

You're probably running in the C locale, which implies an ASCII
encoding. That has caused enough trouble that the Python devs decided
to automatically convert it to UTF-8 in Python 3.7:
https://www.python.org/dev/peps/pep-0538/. LC_CTYPE=C.UTF-8 should fix
it.

It's a bit silly to have it crash for something like that though. I
could force UTF-8 instead of respecting the locale (though it feels
neater to respect settings), or tell Python to ignore decoding errors.
Should probably do something at least...

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap  wrote:
> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>> Hello,
>>
>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>> terminal menuconfig implementation, implemented in plain curses
>> (which is in the Python standard library).
>>
>> The interface should feel familiar to people used to mconf. It has
>> some features that mconf lacks:
>>
>>   - Seamless resizing
>>
>>   - Unicode support
>>
>>   - Runs on Windows (via 'pip install windows-curses', which uses
>> PDCurses)
>>
>>   - Improved information displays:
>>
>> * All expressions are split into readable chunks
>>
>> * Menus and comments have information displays
>>
>>   - Relatively easy-to-read and easy-to-tweak code.
>>
>> Kconfiglib automatically invalidates symbols as needed, and
>> values can never get stale, which helps.
>>
>> Some upcoming features are mouse support and a search feature that
>> can jump directly to the definition of a symbol. The jump-to feature
>> will use a "show-all" mode in case the symbol isn't visible.
>>
>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>> implementation is at
>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>> The docstring at the top has some more information.
>
> Hi,
>
> I'm probably missing some python additive (I hope it's that easy), but
> menuconfig.py is not liking the "degree" symbol in 
> drivers/net/can/peak_canfd/Kconfig:
>
> config CAN_PEAK_PCIEFD
> depends on PCI
> tristate "PEAK-System PCAN-PCIe FD cards"
> ---help---
>   This driver adds support for the PEAK-System PCI Express FD
>   CAN-FD cards family.
>   These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>   CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>   1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>   up to 12 Mbit/s. A galvanic isolation of the CAN ports protects the
>   electronics of the card and the respective computer against
>   disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>   operated with ambient temperatures in a range of -40 to +85 °C.
>
>
> kconfiglib.KconfigSyntaxError:
> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
> Problematic data: b'\xc2'
> Reason: ordinal not in range(128)
>
>
> thanks,
> --
> ~Randy

Thanks for trying it out!

You're probably running in the C locale, which implies an ASCII
encoding. That has caused enough trouble that the Python devs decided
to automatically convert it to UTF-8 in Python 3.7:
https://www.python.org/dev/peps/pep-0538/. LC_CTYPE=C.UTF-8 should fix
it.

It's a bit silly to have it crash for something like that though. I
could force UTF-8 instead of respecting the locale (though it feels
neater to respect settings), or tell Python to ignore decoding errors.
Should probably do something at least...

Cheers,
Ulf

[ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

Hello,

Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
terminal menuconfig implementation, implemented in plain curses
(which is in the Python standard library).

The interface should feel familiar to people used to mconf. It has
some features that mconf lacks:

  - Seamless resizing

  - Unicode support

  - Runs on Windows (via 'pip install windows-curses', which uses
PDCurses)

  - Improved information displays:

* All expressions are split into readable chunks

* Menus and comments have information displays

  - Relatively easy-to-read and easy-to-tweak code.

Kconfiglib automatically invalidates symbols as needed, and
values can never get stale, which helps.

Some upcoming features are mouse support and a search feature that
can jump directly to the definition of a symbol. The jump-to feature
will use a "show-all" mode in case the symbol isn't visible.

See the Kconfiglib GitHub page for screenshots. The menuconfig
implementation is at
https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
The docstring at the top has some more information.

Cheers,
Ulf

[ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

Hello,

Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
terminal menuconfig implementation, implemented in plain curses
(which is in the Python standard library).

The interface should feel familiar to people used to mconf. It has
some features that mconf lacks:

  - Seamless resizing

  - Unicode support

  - Runs on Windows (via 'pip install windows-curses', which uses
PDCurses)

  - Improved information displays:

* All expressions are split into readable chunks

* Menus and comments have information displays

  - Relatively easy-to-read and easy-to-tweak code.

Kconfiglib automatically invalidates symbols as needed, and
values can never get stale, which helps.

Some upcoming features are mouse support and a search feature that
can jump directly to the definition of a symbol. The jump-to feature
will use a "show-all" mode in case the symbol isn't visible.

See the Kconfiglib GitHub page for screenshots. The menuconfig
implementation is at
https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
The docstring at the top has some more information.

Cheers,
Ulf

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
<yamada.masah...@socionext.com> wrote:
> 2018-04-15 17:08 GMT+09:00 Ulf Magnusson <ulfali...@gmail.com>:
>> On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
>> <yamada.masah...@socionext.com> 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 <yamada.masah...@socionext.com>
>>> ---
>>>
>>> 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 supp

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

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 08/30] kconfig: add built-in function support

[Ulf Magnusson]

On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
 wrote:
> This commit adds a new concept 'function' to do more text processing
> in Kconfig.
>
> A function call looks like this:
>
>   $(function arg1, arg2, arg3, ...)
>
> This commit adds the basic infrastructure to expand functions.
> Change the text expansion helpers to take arguments.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Changes in v3:
>   - Split base infrastructure and 'shell' function
> into separate patches.
>
> Changes in v2:
>   - Use 'shell' for getting stdout from the comment.
> It was 'shell-stdout' in the previous version.
>   - Symplify the implementation since the expansion has been moved to
> lexer.
>
>  scripts/kconfig/preprocess.c | 142 
> +++
>  1 file changed, 130 insertions(+), 12 deletions(-)
>
> diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
> index fa4abc8..e77cf7c 100644
> --- a/scripts/kconfig/preprocess.c
> +++ b/scripts/kconfig/preprocess.c
> @@ -8,6 +8,10 @@
>
>  #include "list.h"
>
> +#define ARRAY_SIZE(arr)(sizeof(arr) / sizeof((arr)[0]))
> +
> +static char *expand_string_with_args(const char *in, int argc, char *argv[]);
> +
>  /*
>   * Environment variables
>   */
> @@ -74,9 +78,47 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
> }
>  }
>
> -static char *eval_clause(const char *in)
> +/*
> + * Built-in Functions
> + */
> +struct function {
> +   char *name;
> +   char *(*func)(int argc, char *argv[]);
> +};
> +
> +static const struct function function_table[] = {
> +};
> +
> +static char *function_call(const char *name, int argc, char *argv[])
>  {
> -   char *res, *name;
> +   const struct function *f;
> +   int i;
> +
> +   for (i = 0; i < ARRAY_SIZE(function_table); i++) {
> +   f = _table[i];
> +   if (!strcmp(f->name, name))
> +   return f->func(argc, argv);
> +   }
> +
> +   return NULL;
> +}
> +
> +#define FUNCTION_MAX_ARGS  16
> +
> +/*
> + * Evaluate a clause with arguments.  argc/argv are arguments from the upper
> + * function call.
> + *
> + * Returned string must be freed when done
> + */
> +static char *eval_clause(const char *in, int argc, char *argv[])
> +{
> +   char *tmp, *prev, *p, *res, *name;
> +   char delim = ' ';
> +   int new_argc = 0;
> +   char *new_argv[FUNCTION_MAX_ARGS];
> +   int nest = 0;
> +   int i;
>
> /*
>  * Returns an empty string because '$()' should be evaluated
> @@ -85,10 +127,73 @@ static char *eval_clause(const char *in)
> if (!*in)
> return xstrdup("");
>
> -   name = expand_string(in);
> +   tmp = xstrdup(in);
> +
> +   prev = p = tmp;
>
> -   res = env_expand(name);
> +   /*
> +* Split into tokens
> +* The function name and the first argument are separated by a space.
> +* Arguments are separated by a comma.
> +* For example, if the function call is like this:
> +*   $(foo abc,$(x),$(y))
> +*
> +* The input string for this helper should be:
> +*   foo abc,$(x),$(y)
> +*
> +* and split into:
> +*   new_argv[0]: foo
> +*   new_argv[1]: abc
> +*   new_argv[2]: $(x)
> +*   new_argv[3]: $(y)
> +*/
> +   while (*p) {
> +   if (nest == 0 && *p == delim) {
> +   *p = 0;
> +   new_argv[new_argc++] = prev;

Erroring out would be nicer than overflowing the array.

Cheers,
Ulf

Re: [PATCH 08/30] kconfig: add built-in function support

[Ulf Magnusson]

On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
 wrote:
> This commit adds a new concept 'function' to do more text processing
> in Kconfig.
>
> A function call looks like this:
>
>   $(function arg1, arg2, arg3, ...)
>
> This commit adds the basic infrastructure to expand functions.
> Change the text expansion helpers to take arguments.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Changes in v3:
>   - Split base infrastructure and 'shell' function
> into separate patches.
>
> Changes in v2:
>   - Use 'shell' for getting stdout from the comment.
> It was 'shell-stdout' in the previous version.
>   - Symplify the implementation since the expansion has been moved to
> lexer.
>
>  scripts/kconfig/preprocess.c | 142 
> +++
>  1 file changed, 130 insertions(+), 12 deletions(-)
>
> diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
> index fa4abc8..e77cf7c 100644
> --- a/scripts/kconfig/preprocess.c
> +++ b/scripts/kconfig/preprocess.c
> @@ -8,6 +8,10 @@
>
>  #include "list.h"
>
> +#define ARRAY_SIZE(arr)(sizeof(arr) / sizeof((arr)[0]))
> +
> +static char *expand_string_with_args(const char *in, int argc, char *argv[]);
> +
>  /*
>   * Environment variables
>   */
> @@ -74,9 +78,47 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
> }
>  }
>
> -static char *eval_clause(const char *in)
> +/*
> + * Built-in Functions
> + */
> +struct function {
> +   char *name;
> +   char *(*func)(int argc, char *argv[]);
> +};
> +
> +static const struct function function_table[] = {
> +};
> +
> +static char *function_call(const char *name, int argc, char *argv[])
>  {
> -   char *res, *name;
> +   const struct function *f;
> +   int i;
> +
> +   for (i = 0; i < ARRAY_SIZE(function_table); i++) {
> +   f = _table[i];
> +   if (!strcmp(f->name, name))
> +   return f->func(argc, argv);
> +   }
> +
> +   return NULL;
> +}
> +
> +#define FUNCTION_MAX_ARGS  16
> +
> +/*
> + * Evaluate a clause with arguments.  argc/argv are arguments from the upper
> + * function call.
> + *
> + * Returned string must be freed when done
> + */
> +static char *eval_clause(const char *in, int argc, char *argv[])
> +{
> +   char *tmp, *prev, *p, *res, *name;
> +   char delim = ' ';
> +   int new_argc = 0;
> +   char *new_argv[FUNCTION_MAX_ARGS];
> +   int nest = 0;
> +   int i;
>
> /*
>  * Returns an empty string because '$()' should be evaluated
> @@ -85,10 +127,73 @@ static char *eval_clause(const char *in)
> if (!*in)
> return xstrdup("");
>
> -   name = expand_string(in);
> +   tmp = xstrdup(in);
> +
> +   prev = p = tmp;
>
> -   res = env_expand(name);
> +   /*
> +* Split into tokens
> +* The function name and the first argument are separated by a space.
> +* Arguments are separated by a comma.
> +* For example, if the function call is like this:
> +*   $(foo abc,$(x),$(y))
> +*
> +* The input string for this helper should be:
> +*   foo abc,$(x),$(y)
> +*
> +* and split into:
> +*   new_argv[0]: foo
> +*   new_argv[1]: abc
> +*   new_argv[2]: $(x)
> +*   new_argv[3]: $(y)
> +*/
> +   while (*p) {
> +   if (nest == 0 && *p == delim) {
> +   *p = 0;
> +   new_argv[new_argc++] = prev;

Erroring out would be nicer than overflowing the array.

Cheers,
Ulf

Re: [PATCH 20/30] kconfig: add basic helper macros to scripts/Kconfig.include

[Ulf Magnusson]

On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> Kconfig got text processing tools like we see in Make.  Add Kconfig
> helper macros to scripts/Kconfig.include like we collect Makefile
> macros in scripts/Kbuild.include.
>
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
> Reviewed-by: Kees Cook <keesc...@chromium.org>
> Reviewed-by: Ulf Magnusson <ulfali...@gmail.com>
> ---
>
> Changes in v3:
>   - Move helpers to scripts/Kconfig.include
>
> Changes in v2: None
>
>  Kconfig |  2 ++
>  MAINTAINERS |  1 +
>  scripts/Kconfig.include | 17 +
>  3 files changed, 20 insertions(+)
>  create mode 100644 scripts/Kconfig.include
>
> diff --git a/Kconfig b/Kconfig
> index 5b55d87..a90d9f9 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -7,4 +7,6 @@ mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
>
>  comment "Compiler: $(CC_VERSION_TEXT)"
>
> +source "scripts/Kconfig.include"
> +
>  source "arch/$(SRCARCH)/Kconfig"
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b9dab38..d962f4a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7624,6 +7624,7 @@ L:linux-kbu...@vger.kernel.org
>  S: Maintained
>  F: Documentation/kbuild/kconfig*
>  F: scripts/kconfig/
> +F: scripts/Kconfig.include
>
>  KDUMP
>  M: Dave Young <dyo...@redhat.com>
> diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> new file mode 100644
> index 000..cac7a81
> --- /dev/null
> +++ b/scripts/Kconfig.include
> @@ -0,0 +1,17 @@
> +# Kconfig helper macros
> +
> +# Convenient variables
> +comma   := ,
> +quote   := "
> +squote  := '
> +empty   :=
> +space   := $(empty) $(empty)
> +
> +# y if the command exits with 0, n otherwise
> +success = $(shell ($(1)) >/dev/null 2>&1 && echo y || echo n)

'{ $(1); }' might work here, to avoid the extra subshell.

Shaves 20-30% off the runtime here in a silly
system("(true) >/dev/null 2>&1 && echo y || echo n") vs.
system("{ true; } >/dev/null 2>&1 && echo y || echo n")
comparison.

> +
> +# y if the given compiler flag is supported, n otherwise
> +cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null)
> +
> +# y if the given linker flag is supported, n otherwise
> +ld-option = $(success $(LD) -v $(1))
> --
> 2.7.4
>

Cheers,
Ulf

Re: [PATCH 20/30] kconfig: add basic helper macros to scripts/Kconfig.include

[Ulf Magnusson]

On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
 wrote:
> Kconfig got text processing tools like we see in Make.  Add Kconfig
> helper macros to scripts/Kconfig.include like we collect Makefile
> macros in scripts/Kbuild.include.
>
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Kees Cook 
> Reviewed-by: Ulf Magnusson 
> ---
>
> Changes in v3:
>   - Move helpers to scripts/Kconfig.include
>
> Changes in v2: None
>
>  Kconfig |  2 ++
>  MAINTAINERS |  1 +
>  scripts/Kconfig.include | 17 +
>  3 files changed, 20 insertions(+)
>  create mode 100644 scripts/Kconfig.include
>
> diff --git a/Kconfig b/Kconfig
> index 5b55d87..a90d9f9 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -7,4 +7,6 @@ mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
>
>  comment "Compiler: $(CC_VERSION_TEXT)"
>
> +source "scripts/Kconfig.include"
> +
>  source "arch/$(SRCARCH)/Kconfig"
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b9dab38..d962f4a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7624,6 +7624,7 @@ L:linux-kbu...@vger.kernel.org
>  S: Maintained
>  F: Documentation/kbuild/kconfig*
>  F: scripts/kconfig/
> +F: scripts/Kconfig.include
>
>  KDUMP
>  M: Dave Young 
> diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> new file mode 100644
> index 000..cac7a81
> --- /dev/null
> +++ b/scripts/Kconfig.include
> @@ -0,0 +1,17 @@
> +# Kconfig helper macros
> +
> +# Convenient variables
> +comma   := ,
> +quote   := "
> +squote  := '
> +empty   :=
> +space   := $(empty) $(empty)
> +
> +# y if the command exits with 0, n otherwise
> +success = $(shell ($(1)) >/dev/null 2>&1 && echo y || echo n)

'{ $(1); }' might work here, to avoid the extra subshell.

Shaves 20-30% off the runtime here in a silly
system("(true) >/dev/null 2>&1 && echo y || echo n") vs.
system("{ true; } >/dev/null 2>&1 && echo y || echo n")
comparison.

> +
> +# y if the given compiler flag is supported, n otherwise
> +cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null)
> +
> +# y if the given linker flag is supported, n otherwise
> +ld-option = $(success $(LD) -v $(1))
> --
> 2.7.4
>

Cheers,
Ulf

Re: [PATCH v2 09/21] kconfig: add 'macro' keyword to support user-defined function

[Ulf Magnusson]

On Sun, Apr 1, 2018 at 8:05 AM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
> <yamada.masah...@socionext.com> wrote:
>> Now, we got a basic ability to test compiler capability in Kconfig.
>>
>> config CC_HAS_STACKPROTECTOR
>> def_bool $(shell (($CC -Werror -fstack-protector -c -x c /dev/null 
>> -o /dev/null) && echo y) || echo n)
>>
>> This works, but it is ugly to repeat this long boilerplate.
>>
>> We want to describe like this:
>>
>> config CC_HAS_STACKPROTECTOR
>> bool
>> default $(cc-option -fstack-protector)
>>
>> It is straight-forward to add a new function, but I do not like to
>> hard-code specialized functions like this.  Hence, here is another
>> feature to add functions from Kconfig files.
>>
>> A user-defined function is defined with a special keyword 'macro'.
>> It can be referenced in the same way as built-in functions.  This
>> feature was also inspired by Makefile where user-defined functions
>> are referenced by $(call func-name, args...), but I omitted the 'call'
>> to makes it shorter.
>>
>> The macro definition can contain $(1), $(2), ... which will be replaced
>> with arguments from the caller.  The macro works just as a textual
>> shorthand, which is also expanded in the lexer phase.
>>
>> [Example Code]
>>
>>   macro success $(shell ($(1) && echo y) || echo n)
>>
>>   config TRUE
>>   bool "true"
>>   default $(success true)
>>
>>   config FALSE
>>   bool "false"
>>   default $(success false)
>>
>> [Result]
>>
>>   $ make -s alldefconfig
>>   $ tail -n 2 .config
>>   CONFIG_TRUE=y
>>   # CONFIG_FALSE is not set
>>
>> [Example Code]
>>
>>   macro success $(shell ($(1) && echo y) || echo n)
>>
>>   macro cc-option $(success $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
>>
>>   config CC_HAS_STACKPROTECTOR
>>   def_bool $(cc-option -fstack-protector)
>>
>> [Result]
>>   $ make -s alldefconfig
>>   $ tail -n 1 .config
>>   CONFIG_CC_HAS_STACKPROTECTOR=y
>>
>> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>>
>> Changes in v2:
>>   - Use 'macro' directly instead of inside the string type symbol.
>>
>>  scripts/kconfig/function.c  | 59 
>> +++--
>>  scripts/kconfig/lkc_proto.h |  1 +
>>  scripts/kconfig/zconf.l | 31 
>>  3 files changed, 89 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
>> index 913685f..389bb44 100644
>> --- a/scripts/kconfig/function.c
>> +++ b/scripts/kconfig/function.c
>> @@ -15,6 +15,7 @@ static LIST_HEAD(function_list);
>>  struct function {
>> char *name;
>> char *(*func)(struct function *f, int argc, char *argv[]);
>> +   char *macro;
>> struct list_head node;
>>  };
>>
>> @@ -31,7 +32,8 @@ static struct function *func_lookup(const char *name)
>>  }
>>
>>  static void func_add(const char *name,
>> -char *(*func)(struct function *f, int argc, char 
>> *argv[]))
>> +char *(*func)(struct function *f, int argc, char 
>> *argv[]),
>> +const char *macro)
>>  {
>> struct function *f;
>>
>> @@ -44,6 +46,7 @@ static void func_add(const char *name,
>> f = xmalloc(sizeof(*f));
>> f->name = xstrdup(name);
>> f->func = func;
>> +   f->macro = macro ? xstrdup(macro) : NULL;
>>
>> list_add_tail(>node, _list);
>>  }
>> @@ -51,6 +54,7 @@ static void func_add(const char *name,
>>  static void func_del(struct function *f)
>>  {
>> list_del(>node);
>> +   free(f->macro);
>> free(f->name);
>> free(f);
>>  }
>> @@ -108,6 +112,57 @@ char *func_eval_n(const char *func, size_t n)
>> return res;
>>  }
>>
>> +/* run user-defined function */
>> +static char *do_macro(struct function *f, int argc, char *argv[])
>> +{
>> +   char *new;
>> +   char *src, *p, *res;
>> +   size_t newlen;
>> +   int n;
>> +
>> +   n

Re: [PATCH v2 09/21] kconfig: add 'macro' keyword to support user-defined function

[Ulf Magnusson]

On Sun, Apr 1, 2018 at 8:05 AM, Ulf Magnusson  wrote:
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
>  wrote:
>> Now, we got a basic ability to test compiler capability in Kconfig.
>>
>> config CC_HAS_STACKPROTECTOR
>> def_bool $(shell (($CC -Werror -fstack-protector -c -x c /dev/null 
>> -o /dev/null) && echo y) || echo n)
>>
>> This works, but it is ugly to repeat this long boilerplate.
>>
>> We want to describe like this:
>>
>> config CC_HAS_STACKPROTECTOR
>> bool
>> default $(cc-option -fstack-protector)
>>
>> It is straight-forward to add a new function, but I do not like to
>> hard-code specialized functions like this.  Hence, here is another
>> feature to add functions from Kconfig files.
>>
>> A user-defined function is defined with a special keyword 'macro'.
>> It can be referenced in the same way as built-in functions.  This
>> feature was also inspired by Makefile where user-defined functions
>> are referenced by $(call func-name, args...), but I omitted the 'call'
>> to makes it shorter.
>>
>> The macro definition can contain $(1), $(2), ... which will be replaced
>> with arguments from the caller.  The macro works just as a textual
>> shorthand, which is also expanded in the lexer phase.
>>
>> [Example Code]
>>
>>   macro success $(shell ($(1) && echo y) || echo n)
>>
>>   config TRUE
>>   bool "true"
>>   default $(success true)
>>
>>   config FALSE
>>   bool "false"
>>   default $(success false)
>>
>> [Result]
>>
>>   $ make -s alldefconfig
>>   $ tail -n 2 .config
>>   CONFIG_TRUE=y
>>   # CONFIG_FALSE is not set
>>
>> [Example Code]
>>
>>   macro success $(shell ($(1) && echo y) || echo n)
>>
>>   macro cc-option $(success $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
>>
>>   config CC_HAS_STACKPROTECTOR
>>   def_bool $(cc-option -fstack-protector)
>>
>> [Result]
>>   $ make -s alldefconfig
>>   $ tail -n 1 .config
>>   CONFIG_CC_HAS_STACKPROTECTOR=y
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>>
>> Changes in v2:
>>   - Use 'macro' directly instead of inside the string type symbol.
>>
>>  scripts/kconfig/function.c  | 59 
>> +++--
>>  scripts/kconfig/lkc_proto.h |  1 +
>>  scripts/kconfig/zconf.l | 31 
>>  3 files changed, 89 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
>> index 913685f..389bb44 100644
>> --- a/scripts/kconfig/function.c
>> +++ b/scripts/kconfig/function.c
>> @@ -15,6 +15,7 @@ static LIST_HEAD(function_list);
>>  struct function {
>> char *name;
>> char *(*func)(struct function *f, int argc, char *argv[]);
>> +   char *macro;
>> struct list_head node;
>>  };
>>
>> @@ -31,7 +32,8 @@ static struct function *func_lookup(const char *name)
>>  }
>>
>>  static void func_add(const char *name,
>> -char *(*func)(struct function *f, int argc, char 
>> *argv[]))
>> +char *(*func)(struct function *f, int argc, char 
>> *argv[]),
>> +const char *macro)
>>  {
>> struct function *f;
>>
>> @@ -44,6 +46,7 @@ static void func_add(const char *name,
>> f = xmalloc(sizeof(*f));
>> f->name = xstrdup(name);
>> f->func = func;
>> +   f->macro = macro ? xstrdup(macro) : NULL;
>>
>> list_add_tail(>node, _list);
>>  }
>> @@ -51,6 +54,7 @@ static void func_add(const char *name,
>>  static void func_del(struct function *f)
>>  {
>> list_del(>node);
>> +   free(f->macro);
>> free(f->name);
>> free(f);
>>  }
>> @@ -108,6 +112,57 @@ char *func_eval_n(const char *func, size_t n)
>> return res;
>>  }
>>
>> +/* run user-defined function */
>> +static char *do_macro(struct function *f, int argc, char *argv[])
>> +{
>> +   char *new;
>> +   char *src, *p, *res;
>> +   size_t newlen;
>> +   int n;
>> +
>> +   new = xmalloc(1);
>> +   *new = 0;
>
> new = '\0' would be consistent with the rest of th

Re: [PATCH v2 10/21] kconfig: add 'success' and 'cc-option' macros

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> 'cc-option' will be the most frequently used macro.  It evaluates to 'y'
> if the given argument is supported by the compiler, or 'n' otherwise.
>
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
> ---
>
> Changes in v2:
>   - Implement 'success' as a macro
>
>  init/Kconfig | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 0d6fe20..c456030 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -8,6 +8,12 @@ config DEFCONFIG_LIST
> default ARCH_DEFCONFIG
> default "arch/$ARCH/defconfig"
>
> +# expanded to y if the command exits with 0, n otherwise
> +macro success $(shell ($(1) && echo y) || echo n)
> +
> +# expanded to y if the given compiler flag is supported, n otherwise
> +macro cc-option $(success $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
> +
>  config CONSTRUCTORS
> bool
> depends on !UML
> --
> 2.7.4
>

Reviewed-by: Ulf Magnusson <ulfali...@gmail.com>

Some other tests (e.g. scripts/*-stack-protector.sh) also pass -S and
-O0 and stuff to speed things up. Feels like that could lead to
gotchas though.

-S does help a bit at least:

$ time gcc -c -x c /dev/null -o /dev/null
real 0m0.020s
user 0m0.013s
sys 0m0.007s

$ time gcc -S -x c /dev/null -o /dev/null
real 0m0.012s
user 0m0.009s
sys 0m0.003s

Re: [PATCH v2 10/21] kconfig: add 'success' and 'cc-option' macros

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
 wrote:
> 'cc-option' will be the most frequently used macro.  It evaluates to 'y'
> if the given argument is supported by the compiler, or 'n' otherwise.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Changes in v2:
>   - Implement 'success' as a macro
>
>  init/Kconfig | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 0d6fe20..c456030 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -8,6 +8,12 @@ config DEFCONFIG_LIST
> default ARCH_DEFCONFIG
> default "arch/$ARCH/defconfig"
>
> +# expanded to y if the command exits with 0, n otherwise
> +macro success $(shell ($(1) && echo y) || echo n)
> +
> +# expanded to y if the given compiler flag is supported, n otherwise
> +macro cc-option $(success $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
> +
>  config CONSTRUCTORS
> bool
> depends on !UML
> --
> 2.7.4
>

Reviewed-by: Ulf Magnusson 

Some other tests (e.g. scripts/*-stack-protector.sh) also pass -S and
-O0 and stuff to speed things up. Feels like that could lead to
gotchas though.

-S does help a bit at least:

$ time gcc -c -x c /dev/null -o /dev/null
real 0m0.020s
user 0m0.013s
sys 0m0.007s

$ time gcc -S -x c /dev/null -o /dev/null
real 0m0.012s
user 0m0.009s
sys 0m0.003s

Re: [PATCH v2 09/21] kconfig: add 'macro' keyword to support user-defined function

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
 wrote:
> Now, we got a basic ability to test compiler capability in Kconfig.
>
> config CC_HAS_STACKPROTECTOR
> def_bool $(shell (($CC -Werror -fstack-protector -c -x c /dev/null -o 
> /dev/null) && echo y) || echo n)
>
> This works, but it is ugly to repeat this long boilerplate.
>
> We want to describe like this:
>
> config CC_HAS_STACKPROTECTOR
> bool
> default $(cc-option -fstack-protector)
>
> It is straight-forward to add a new function, but I do not like to
> hard-code specialized functions like this.  Hence, here is another
> feature to add functions from Kconfig files.
>
> A user-defined function is defined with a special keyword 'macro'.
> It can be referenced in the same way as built-in functions.  This
> feature was also inspired by Makefile where user-defined functions
> are referenced by $(call func-name, args...), but I omitted the 'call'
> to makes it shorter.
>
> The macro definition can contain $(1), $(2), ... which will be replaced
> with arguments from the caller.  The macro works just as a textual
> shorthand, which is also expanded in the lexer phase.
>
> [Example Code]
>
>   macro success $(shell ($(1) && echo y) || echo n)
>
>   config TRUE
>   bool "true"
>   default $(success true)
>
>   config FALSE
>   bool "false"
>   default $(success false)
>
> [Result]
>
>   $ make -s alldefconfig
>   $ tail -n 2 .config
>   CONFIG_TRUE=y
>   # CONFIG_FALSE is not set
>
> [Example Code]
>
>   macro success $(shell ($(1) && echo y) || echo n)
>
>   macro cc-option $(success $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
>
>   config CC_HAS_STACKPROTECTOR
>   def_bool $(cc-option -fstack-protector)
>
> [Result]
>   $ make -s alldefconfig
>   $ tail -n 1 .config
>   CONFIG_CC_HAS_STACKPROTECTOR=y
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Reminder for myself:
> Update Documentation/kbuild/kconfig-language.txt
>
> Changes in v2:
>   - Use 'macro' directly instead of inside the string type symbol.
>
>  scripts/kconfig/function.c  | 59 
> +++--
>  scripts/kconfig/lkc_proto.h |  1 +
>  scripts/kconfig/zconf.l | 31 
>  3 files changed, 89 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
> index 913685f..389bb44 100644
> --- a/scripts/kconfig/function.c
> +++ b/scripts/kconfig/function.c
> @@ -15,6 +15,7 @@ static LIST_HEAD(function_list);
>  struct function {
> char *name;
> char *(*func)(struct function *f, int argc, char *argv[]);
> +   char *macro;
> struct list_head node;
>  };
>
> @@ -31,7 +32,8 @@ static struct function *func_lookup(const char *name)
>  }
>
>  static void func_add(const char *name,
> -char *(*func)(struct function *f, int argc, char 
> *argv[]))
> +char *(*func)(struct function *f, int argc, char 
> *argv[]),
> +const char *macro)
>  {
> struct function *f;
>
> @@ -44,6 +46,7 @@ static void func_add(const char *name,
> f = xmalloc(sizeof(*f));
> f->name = xstrdup(name);
> f->func = func;
> +   f->macro = macro ? xstrdup(macro) : NULL;
>
> list_add_tail(>node, _list);
>  }
> @@ -51,6 +54,7 @@ static void func_add(const char *name,
>  static void func_del(struct function *f)
>  {
> list_del(>node);
> +   free(f->macro);
> free(f->name);
> free(f);
>  }
> @@ -108,6 +112,57 @@ char *func_eval_n(const char *func, size_t n)
> return res;
>  }
>
> +/* run user-defined function */
> +static char *do_macro(struct function *f, int argc, char *argv[])
> +{
> +   char *new;
> +   char *src, *p, *res;
> +   size_t newlen;
> +   int n;
> +
> +   new = xmalloc(1);
> +   *new = 0;

new = '\0' would be consistent with the rest of the code.

> +
> +   /*
> +* This is a format string. $(1), $(2), ... must be replaced with
> +* function arguments.
> +*/
> +   src = f->macro;
> +   p = src;
> +
> +   while ((p = strstr(p, "$("))) {
> +   if (isdigit(p[2]) && p[3] == ')') {
> +   n = p[2] - '0';
> +   if (n < argc) {
> +   newlen = strlen(new) + (p - src) +
> +   strlen(argv[n]) + 1;
> +   new = xrealloc(new, newlen);
> +   strncat(new, src, p - src);
> +   strcat(new, argv[n]);
> +   src = p + 4;
> +   }

Might be nice to warn when a macro call has missing arguments.

> +   p += 2;
> +   }
> +   p += 2;
> +   }

I had to stare at this for a while to see how it 

Re: [PATCH v2 09/21] kconfig: add 'macro' keyword to support user-defined function

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
 wrote:
> Now, we got a basic ability to test compiler capability in Kconfig.
>
> config CC_HAS_STACKPROTECTOR
> def_bool $(shell (($CC -Werror -fstack-protector -c -x c /dev/null -o 
> /dev/null) && echo y) || echo n)
>
> This works, but it is ugly to repeat this long boilerplate.
>
> We want to describe like this:
>
> config CC_HAS_STACKPROTECTOR
> bool
> default $(cc-option -fstack-protector)
>
> It is straight-forward to add a new function, but I do not like to
> hard-code specialized functions like this.  Hence, here is another
> feature to add functions from Kconfig files.
>
> A user-defined function is defined with a special keyword 'macro'.
> It can be referenced in the same way as built-in functions.  This
> feature was also inspired by Makefile where user-defined functions
> are referenced by $(call func-name, args...), but I omitted the 'call'
> to makes it shorter.
>
> The macro definition can contain $(1), $(2), ... which will be replaced
> with arguments from the caller.  The macro works just as a textual
> shorthand, which is also expanded in the lexer phase.
>
> [Example Code]
>
>   macro success $(shell ($(1) && echo y) || echo n)
>
>   config TRUE
>   bool "true"
>   default $(success true)
>
>   config FALSE
>   bool "false"
>   default $(success false)
>
> [Result]
>
>   $ make -s alldefconfig
>   $ tail -n 2 .config
>   CONFIG_TRUE=y
>   # CONFIG_FALSE is not set
>
> [Example Code]
>
>   macro success $(shell ($(1) && echo y) || echo n)
>
>   macro cc-option $(success $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
>
>   config CC_HAS_STACKPROTECTOR
>   def_bool $(cc-option -fstack-protector)
>
> [Result]
>   $ make -s alldefconfig
>   $ tail -n 1 .config
>   CONFIG_CC_HAS_STACKPROTECTOR=y
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Reminder for myself:
> Update Documentation/kbuild/kconfig-language.txt
>
> Changes in v2:
>   - Use 'macro' directly instead of inside the string type symbol.
>
>  scripts/kconfig/function.c  | 59 
> +++--
>  scripts/kconfig/lkc_proto.h |  1 +
>  scripts/kconfig/zconf.l | 31 
>  3 files changed, 89 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
> index 913685f..389bb44 100644
> --- a/scripts/kconfig/function.c
> +++ b/scripts/kconfig/function.c
> @@ -15,6 +15,7 @@ static LIST_HEAD(function_list);
>  struct function {
> char *name;
> char *(*func)(struct function *f, int argc, char *argv[]);
> +   char *macro;
> struct list_head node;
>  };
>
> @@ -31,7 +32,8 @@ static struct function *func_lookup(const char *name)
>  }
>
>  static void func_add(const char *name,
> -char *(*func)(struct function *f, int argc, char 
> *argv[]))
> +char *(*func)(struct function *f, int argc, char 
> *argv[]),
> +const char *macro)
>  {
> struct function *f;
>
> @@ -44,6 +46,7 @@ static void func_add(const char *name,
> f = xmalloc(sizeof(*f));
> f->name = xstrdup(name);
> f->func = func;
> +   f->macro = macro ? xstrdup(macro) : NULL;
>
> list_add_tail(>node, _list);
>  }
> @@ -51,6 +54,7 @@ static void func_add(const char *name,
>  static void func_del(struct function *f)
>  {
> list_del(>node);
> +   free(f->macro);
> free(f->name);
> free(f);
>  }
> @@ -108,6 +112,57 @@ char *func_eval_n(const char *func, size_t n)
> return res;
>  }
>
> +/* run user-defined function */
> +static char *do_macro(struct function *f, int argc, char *argv[])
> +{
> +   char *new;
> +   char *src, *p, *res;
> +   size_t newlen;
> +   int n;
> +
> +   new = xmalloc(1);
> +   *new = 0;

new = '\0' would be consistent with the rest of the code.

> +
> +   /*
> +* This is a format string. $(1), $(2), ... must be replaced with
> +* function arguments.
> +*/
> +   src = f->macro;
> +   p = src;
> +
> +   while ((p = strstr(p, "$("))) {
> +   if (isdigit(p[2]) && p[3] == ')') {
> +   n = p[2] - '0';
> +   if (n < argc) {
> +   newlen = strlen(new) + (p - src) +
> +   strlen(argv[n]) + 1;
> +   new = xrealloc(new, newlen);
> +   strncat(new, src, p - src);
> +   strcat(new, argv[n]);
> +   src = p + 4;
> +   }

Might be nice to warn when a macro call has missing arguments.

> +   p += 2;
> +   }
> +   p += 2;
> +   }

I had to stare at this for a while to see how it worked. What do you
think of this tweak?

while ((p = strstr(p, 

Re: [PATCH v2 08/21] kconfig: replace $UNAME_RELEASE with function call

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> Now that 'shell' function is supported, this can be self-contained in
> Kconfig.
>
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>

Reviewed-by: Ulf Magnusson <ulfali...@gmail.com>

Re: [PATCH v2 08/21] kconfig: replace $UNAME_RELEASE with function call

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
 wrote:
> Now that 'shell' function is supported, this can be self-contained in
> Kconfig.
>
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Ulf Magnusson 

Re: [PATCH v2 07/21] kconfig: add function support and implement 'shell' function

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
 wrote:
> This commit adds a new concept 'function' to do more text processing
> in Kconfig.
>
> A function call looks like this:
>
>   $(function arg1, arg2, arg3, ...)
>
> (Actually, this syntax was inspired by make.)
>
> Real examples will look like this:
>
>   $(shell echo hello world)
>   $(cc-option -fstackprotector)
>
> This commit adds the basic infrastructure to add, delete, evaluate
> functions, and also the first built-in function $(shell ...).  This
> accepts a single command to execute.  It returns the standard output
> from it.
>
> [Example code]
>
>   config HELLO
>   string
>   default "$(shell echo hello world)"
>
>   config Y
>   def_bool $(shell echo y)
>
> [Result]
>
>   $ make -s alldefconfig && tail -n 2 .config
>   CONFIG_HELLO="hello world"
>   CONFIG_Y=y
>
> Caveat:
> Like environments, functions are expanded in the lexer.  You cannot
> pass symbols to function arguments.  This is a limitation to simplify
> the implementation.  I want to avoid the dynamic function evaluation,
> which would introduce much more complexity.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Reminder for myself:
> Update Documentation/kbuild/kconfig-language.txt
>
>
> Changes in v2:
>   - Use 'shell' for getting stdout from the comment.
> It was 'shell-stdout' in the previous version.
>   - Symplify the implementation since the expansion has been moved to
> lexer.
>
>  scripts/kconfig/function.c  | 170 
> 
>  scripts/kconfig/lkc_proto.h |   5 ++
>  scripts/kconfig/util.c  |  46 +---
>  scripts/kconfig/zconf.y |   9 +++
>  4 files changed, 222 insertions(+), 8 deletions(-)
>  create mode 100644 scripts/kconfig/function.c
>
> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
> new file mode 100644
> index 000..913685f
> --- /dev/null
> +++ b/scripts/kconfig/function.c
> @@ -0,0 +1,170 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2018 Masahiro Yamada 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "list.h"
> +
> +#define FUNCTION_MAX_ARGS  10
> +
> +static LIST_HEAD(function_list);
> +
> +struct function {
> +   char *name;
> +   char *(*func)(struct function *f, int argc, char *argv[]);
> +   struct list_head node;
> +};
> +
> +static struct function *func_lookup(const char *name)
> +{
> +   struct function *f;
> +
> +   list_for_each_entry(f, _list, node) {
> +   if (!strcmp(name, f->name))
> +   return f;
> +   }
> +
> +   return NULL;
> +}
> +
> +static void func_add(const char *name,
> +char *(*func)(struct function *f, int argc, char 
> *argv[]))
> +{
> +   struct function *f;
> +
> +   f = func_lookup(name);
> +   if (f) {
> +   fprintf(stderr, "%s: function already exists. ignored.\n", 
> name);
> +   return;
> +   }
> +
> +   f = xmalloc(sizeof(*f));
> +   f->name = xstrdup(name);
> +   f->func = func;
> +
> +   list_add_tail(>node, _list);
> +}
> +
> +static void func_del(struct function *f)
> +{
> +   list_del(>node);
> +   free(f->name);
> +   free(f);
> +}
> +
> +static char *func_call(int argc, char *argv[])
> +{
> +   struct function *f;
> +
> +   f = func_lookup(argv[0]);
> +   if (!f) {
> +   fprintf(stderr, "%s: function not found\n", argv[0]);
> +   return NULL;
> +   }
> +
> +   return f->func(f, argc, argv);
> +}
> +
> +static char *func_eval(const char *func)
> +{
> +   char *expanded, *saveptr, *str, *token, *res;
> +   const char *delim;
> +   int argc = 0;
> +   char *argv[FUNCTION_MAX_ARGS];
> +
> +   expanded = expand_string_value(func);
> +
> +   str = expanded;
> +   delim = " ";
> +
> +   while ((token = strtok_r(str, delim, ))) {
> +   argv[argc++] = token;

Would be nice to error out if the array is overstepped.

> +   str = NULL;
> +   delim = ",";
> +   }
> +
> +   res = func_call(argc, argv);
> +
> +   free(expanded);
> +
> +   return res ?: xstrdup("");
> +}

Since only 'macro' will take multiple parameters, I wonder if it might
be better to implement the argument parsing there, and simply pass the
string (minus the function name) as-is to functions.

You would then be able to have ',' in shell commands, which might be
required -- think gcc -Wl,option and the like.

> +
> +char *func_eval_n(const char *func, size_t n)
> +{
> +   char *tmp, *res;
> +
> +   tmp = xmalloc(n + 1);
> +   memcpy(tmp, func, n);
> +   *(tmp + n) = '\0';
> +
> +   res = func_eval(tmp);
> +
> +   free(tmp);
> +
> +   return res;
> +}
> +
> +/* built-in functions */
> +static char *do_shell(struct 

Re: [PATCH v2 07/21] kconfig: add function support and implement 'shell' function

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
 wrote:
> This commit adds a new concept 'function' to do more text processing
> in Kconfig.
>
> A function call looks like this:
>
>   $(function arg1, arg2, arg3, ...)
>
> (Actually, this syntax was inspired by make.)
>
> Real examples will look like this:
>
>   $(shell echo hello world)
>   $(cc-option -fstackprotector)
>
> This commit adds the basic infrastructure to add, delete, evaluate
> functions, and also the first built-in function $(shell ...).  This
> accepts a single command to execute.  It returns the standard output
> from it.
>
> [Example code]
>
>   config HELLO
>   string
>   default "$(shell echo hello world)"
>
>   config Y
>   def_bool $(shell echo y)
>
> [Result]
>
>   $ make -s alldefconfig && tail -n 2 .config
>   CONFIG_HELLO="hello world"
>   CONFIG_Y=y
>
> Caveat:
> Like environments, functions are expanded in the lexer.  You cannot
> pass symbols to function arguments.  This is a limitation to simplify
> the implementation.  I want to avoid the dynamic function evaluation,
> which would introduce much more complexity.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Reminder for myself:
> Update Documentation/kbuild/kconfig-language.txt
>
>
> Changes in v2:
>   - Use 'shell' for getting stdout from the comment.
> It was 'shell-stdout' in the previous version.
>   - Symplify the implementation since the expansion has been moved to
> lexer.
>
>  scripts/kconfig/function.c  | 170 
> 
>  scripts/kconfig/lkc_proto.h |   5 ++
>  scripts/kconfig/util.c  |  46 +---
>  scripts/kconfig/zconf.y |   9 +++
>  4 files changed, 222 insertions(+), 8 deletions(-)
>  create mode 100644 scripts/kconfig/function.c
>
> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
> new file mode 100644
> index 000..913685f
> --- /dev/null
> +++ b/scripts/kconfig/function.c
> @@ -0,0 +1,170 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2018 Masahiro Yamada 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "list.h"
> +
> +#define FUNCTION_MAX_ARGS  10
> +
> +static LIST_HEAD(function_list);
> +
> +struct function {
> +   char *name;
> +   char *(*func)(struct function *f, int argc, char *argv[]);
> +   struct list_head node;
> +};
> +
> +static struct function *func_lookup(const char *name)
> +{
> +   struct function *f;
> +
> +   list_for_each_entry(f, _list, node) {
> +   if (!strcmp(name, f->name))
> +   return f;
> +   }
> +
> +   return NULL;
> +}
> +
> +static void func_add(const char *name,
> +char *(*func)(struct function *f, int argc, char 
> *argv[]))
> +{
> +   struct function *f;
> +
> +   f = func_lookup(name);
> +   if (f) {
> +   fprintf(stderr, "%s: function already exists. ignored.\n", 
> name);
> +   return;
> +   }
> +
> +   f = xmalloc(sizeof(*f));
> +   f->name = xstrdup(name);
> +   f->func = func;
> +
> +   list_add_tail(>node, _list);
> +}
> +
> +static void func_del(struct function *f)
> +{
> +   list_del(>node);
> +   free(f->name);
> +   free(f);
> +}
> +
> +static char *func_call(int argc, char *argv[])
> +{
> +   struct function *f;
> +
> +   f = func_lookup(argv[0]);
> +   if (!f) {
> +   fprintf(stderr, "%s: function not found\n", argv[0]);
> +   return NULL;
> +   }
> +
> +   return f->func(f, argc, argv);
> +}
> +
> +static char *func_eval(const char *func)
> +{
> +   char *expanded, *saveptr, *str, *token, *res;
> +   const char *delim;
> +   int argc = 0;
> +   char *argv[FUNCTION_MAX_ARGS];
> +
> +   expanded = expand_string_value(func);
> +
> +   str = expanded;
> +   delim = " ";
> +
> +   while ((token = strtok_r(str, delim, ))) {
> +   argv[argc++] = token;

Would be nice to error out if the array is overstepped.

> +   str = NULL;
> +   delim = ",";
> +   }
> +
> +   res = func_call(argc, argv);
> +
> +   free(expanded);
> +
> +   return res ?: xstrdup("");
> +}

Since only 'macro' will take multiple parameters, I wonder if it might
be better to implement the argument parsing there, and simply pass the
string (minus the function name) as-is to functions.

You would then be able to have ',' in shell commands, which might be
required -- think gcc -Wl,option and the like.

> +
> +char *func_eval_n(const char *func, size_t n)
> +{
> +   char *tmp, *res;
> +
> +   tmp = xmalloc(n + 1);
> +   memcpy(tmp, func, n);
> +   *(tmp + n) = '\0';
> +
> +   res = func_eval(tmp);
> +
> +   free(tmp);
> +
> +   return res;
> +}
> +
> +/* built-in functions */
> +static char *do_shell(struct function *f, int argc, char *argv[])
> +{
> +   static const char *pre = "(";
> +   static 

Re: [PATCH v2 06/21] kconfig: remove string expansion for mainmenu after yyparse()

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> Now that environments are expanded in the lexer, conf_parse() does
> not need to explicitly expand $ARCH and $KERNELVERSION in the mainmenu.
>
> The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak
> main menus during parsing") can go away.
>
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>

Reviewed-by: Ulf Magnusson <ulfali...@gmail.com>

Re: [PATCH v2 06/21] kconfig: remove string expansion for mainmenu after yyparse()

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
 wrote:
> Now that environments are expanded in the lexer, conf_parse() does
> not need to explicitly expand $ARCH and $KERNELVERSION in the mainmenu.
>
> The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak
> main menus during parsing") can go away.
>
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Ulf Magnusson 

Re: [PATCH v2 05/21] kconfig: remove string expansion in file_lookup()

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> There are two callers of file_lookup().
>
> [1] zconf_initscan()
> This is used to open the first Kconfig.  However, it cannot
> contain environments in the file path because zconf_fopen() is
> called before file_lookup().  By swapping the call order,
> KBUILD_KCONFIG would be able to contain environments, but I do
> not see practical benefits to support it.
>
> [2] zconf_nextfile()
> This is used to open the next file from 'source' statement like
> source "arch/$SRCARCH/Kconfig"
> but this has already been expanded in the lexer phase.
>
> So, file_lookup() does not need to expand the given path.
>
> By the way, file_lookup() was already buggy; it expanded a given path,
> but it used the path before expansion for look-up:
> if (!strcmp(name, file->name)) {
>
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>

s/environments/environment variables/

Reviewed-by: Ulf Magnusson <ulfali...@gmail.com>

Re: [PATCH v2 05/21] kconfig: remove string expansion in file_lookup()

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
 wrote:
> There are two callers of file_lookup().
>
> [1] zconf_initscan()
> This is used to open the first Kconfig.  However, it cannot
> contain environments in the file path because zconf_fopen() is
> called before file_lookup().  By swapping the call order,
> KBUILD_KCONFIG would be able to contain environments, but I do
> not see practical benefits to support it.
>
> [2] zconf_nextfile()
> This is used to open the next file from 'source' statement like
> source "arch/$SRCARCH/Kconfig"
> but this has already been expanded in the lexer phase.
>
> So, file_lookup() does not need to expand the given path.
>
> By the way, file_lookup() was already buggy; it expanded a given path,
> but it used the path before expansion for look-up:
> if (!strcmp(name, file->name)) {
>
> Signed-off-by: Masahiro Yamada 

s/environments/environment variables/

Reviewed-by: Ulf Magnusson 

Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax

[Ulf Magnusson]

On Sun, Apr 1, 2018 at 4:27 AM, Ulf Magnusson <ulfali...@gmail.com> wrote:
>
> AFAICS, we only need the following functionality:
>
> 1. Record referenced environment variables along with their value
>
> 2. Go through all the recorded environment variables and write
> dependency information
>
> For (1), I think it would be better to simply have env_list_add() (or
> some other suitable name) add the variable to the list if it isn't
> already there (like a kind of set). It is always safe to get the value
> of the environment variable from getenv(), and that seems less
> confusing.
>

env_list_lookup() could be removed then as well.

Cheers,
Ulf

Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax

[Ulf Magnusson]

On Sun, Apr 1, 2018 at 4:27 AM, Ulf Magnusson  wrote:
>
> AFAICS, we only need the following functionality:
>
> 1. Record referenced environment variables along with their value
>
> 2. Go through all the recorded environment variables and write
> dependency information
>
> For (1), I think it would be better to simply have env_list_add() (or
> some other suitable name) add the variable to the list if it isn't
> already there (like a kind of set). It is always safe to get the value
> of the environment variable from getenv(), and that seems less
> confusing.
>

env_list_lookup() could be removed then as well.

Cheers,
Ulf

Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax

[Ulf Magnusson]

Here's a more in-depth review:

On Tue, Mar 27, 2018 at 7:29 AM, 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',

"Environment variables" would be clearer. I've never seen them called
"environments".

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

s/environments/environment variables/

> 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 
> ---
>
> I tested all 'make *config' for arch architectures.
> I confirmed this commit still produced the same result
> (by my kconfig test tool).
>
>
> Changes in v2:
>   - Move the string expansion to the lexer phase.
>   - Split environment helpers to env.c
>
>  Documentation/kbuild/kconfig-language.txt |  8 ---
>  Kconfig   |  4 --
>  Makefile  |  3 +-
>  arch/sh/Kconfig   |  4 +-
>  arch/sparc/Kconfig|  4 +-
>  arch/tile/Kconfig |  2 +-
>  arch/um/Kconfig.common|  4 --
>  arch/x86/Kconfig  |  4 +-
>  arch/x86/um/Kconfig   |  4 +-
>  init/Kconfig  | 10 +---
>  scripts/kconfig/confdata.c| 31 +-
>  scripts/kconfig/env.c | 95 
> +++
>  scripts/kconfig/kconf_id.c|  1 -
>  scripts/kconfig/lkc.h |  8 +--
>  scripts/kconfig/menu.c|  3 -
>  scripts/kconfig/symbol.c  | 56 --
>  scripts/kconfig/util.c| 75 
>  scripts/kconfig/zconf.l   | 20 ++-
>  scripts/kconfig/zconf.y   |  2 +-
>  19 files changed, 158 insertions(+), 180 deletions(-)
>  create mode 100644 scripts/kconfig/env.c
>
> diff --git a/Documentation/kbuild/kconfig-language.txt 
> b/Documentation/kbuild/kconfig-language.txt
> index f5b9493..0e966e8 100644
> --- a/Documentation/kbuild/kconfig-language.txt
> +++ b/Documentation/kbuild/kconfig-language.txt
> @@ -198,14 +198,6 @@ applicable everywhere (see syntax).
>  enables the third modular state for all config symbols.
>  At most one symbol may have the "modules" option set.
>
> -  - "env"=
> -This imports the environment variable into Kconfig. It behaves like
> -a default, except that the value comes from the environment, this
> -also means that the behaviour when mixing it with normal defaults is
> -undefined at this point. The symbol is currently not exported back
> -to the build environment (if this is desired, it can be done via
> -another symbol).
> -

The new behavior needs to be documented later as well (but iirc you
already mentioned that somewhere else).

>- "allnoconfig_y"
>  This declares the symbol as one that should have the value y when
>  using "allnoconfig". Used for symbols that hide other symbols.
> diff --git a/Kconfig b/Kconfig
> index 8c4c1cb..e6ece5b 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -5,8 +5,4 @@
>  #
>  mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"
>
> -config SRCARCH
> -   string
> -   option env="SRCARCH"
> -
>  source "arch/$SRCARCH/Kconfig"
> diff --git a/Makefile 

Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax

[Ulf Magnusson]

Here's a more in-depth review:

On Tue, Mar 27, 2018 at 7:29 AM, 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',

"Environment variables" would be clearer. I've never seen them called
"environments".

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

s/environments/environment variables/

> 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 
> ---
>
> I tested all 'make *config' for arch architectures.
> I confirmed this commit still produced the same result
> (by my kconfig test tool).
>
>
> Changes in v2:
>   - Move the string expansion to the lexer phase.
>   - Split environment helpers to env.c
>
>  Documentation/kbuild/kconfig-language.txt |  8 ---
>  Kconfig   |  4 --
>  Makefile  |  3 +-
>  arch/sh/Kconfig   |  4 +-
>  arch/sparc/Kconfig|  4 +-
>  arch/tile/Kconfig |  2 +-
>  arch/um/Kconfig.common|  4 --
>  arch/x86/Kconfig  |  4 +-
>  arch/x86/um/Kconfig   |  4 +-
>  init/Kconfig  | 10 +---
>  scripts/kconfig/confdata.c| 31 +-
>  scripts/kconfig/env.c | 95 
> +++
>  scripts/kconfig/kconf_id.c|  1 -
>  scripts/kconfig/lkc.h |  8 +--
>  scripts/kconfig/menu.c|  3 -
>  scripts/kconfig/symbol.c  | 56 --
>  scripts/kconfig/util.c| 75 
>  scripts/kconfig/zconf.l   | 20 ++-
>  scripts/kconfig/zconf.y   |  2 +-
>  19 files changed, 158 insertions(+), 180 deletions(-)
>  create mode 100644 scripts/kconfig/env.c
>
> diff --git a/Documentation/kbuild/kconfig-language.txt 
> b/Documentation/kbuild/kconfig-language.txt
> index f5b9493..0e966e8 100644
> --- a/Documentation/kbuild/kconfig-language.txt
> +++ b/Documentation/kbuild/kconfig-language.txt
> @@ -198,14 +198,6 @@ applicable everywhere (see syntax).
>  enables the third modular state for all config symbols.
>  At most one symbol may have the "modules" option set.
>
> -  - "env"=
> -This imports the environment variable into Kconfig. It behaves like
> -a default, except that the value comes from the environment, this
> -also means that the behaviour when mixing it with normal defaults is
> -undefined at this point. The symbol is currently not exported back
> -to the build environment (if this is desired, it can be done via
> -another symbol).
> -

The new behavior needs to be documented later as well (but iirc you
already mentioned that somewhere else).

>- "allnoconfig_y"
>  This declares the symbol as one that should have the value y when
>  using "allnoconfig". Used for symbols that hide other symbols.
> diff --git a/Kconfig b/Kconfig
> index 8c4c1cb..e6ece5b 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -5,8 +5,4 @@
>  #
>  mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"
>
> -config SRCARCH
> -   string
> -   option env="SRCARCH"
> -
>  source "arch/$SRCARCH/Kconfig"
> diff --git a/Makefile b/Makefile
> index 5c395ed..4ae1486 100644
> --- a/Makefile
> 

Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax

[Ulf Magnusson]

On Thu, Mar 29, 2018 at 4:56 AM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Thu, Mar 29, 2018 at 4:19 AM, Ulf Magnusson <ulfali...@gmail.com> wrote:
>> I've been kinda busy lately, so that's why I disappeared.
>>
>> I'll try to go over this patchset in more detail over the weekend.
>>
>> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
>> <yamada.masah...@socionext.com> 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.masah...@socionext.com>
>>> ---
>>>
>>> I tested all 'make *config' for arch architectures.
>>> I confirmed this commit still produced the same result
>>> (by my kconfig test tool).
>>>
>>>
>>> Changes in v2:
>>>   - Move the string expansion to the lexer phase.
>>>   - Split environment helpers to env.c
>>>
>>>  Documentation/kbuild/kconfig-language.txt |  8 ---
>>>  Kconfig   |  4 --
>>>  Makefile  |  3 +-
>>>  arch/sh/Kconfig   |  4 +-
>>>  arch/sparc/Kconfig|  4 +-
>>>  arch/tile/Kconfig |  2 +-
>>>  arch/um/Kconfig.common|  4 --
>>>  arch/x86/Kconfig  |  4 +-
>>>  arch/x86/um/Kconfig   |  4 +-
>>>  init/Kconfig  | 10 +---
>>>  scripts/kconfig/confdata.c| 31 +-
>>>  scripts/kconfig/env.c | 95 
>>> +++
>>>  scripts/kconfig/kconf_id.c|  1 -
>>>  scripts/kconfig/lkc.h |  8 +--
>>>  scripts/kconfig/menu.c|  3 -
>>>  scripts/kconfig/symbol.c  | 56 --
>>>  scripts/kconfig/util.c| 75 
>>>  scripts/kconfig/zconf.l   | 20 ++-
>>>  scripts/kconfig/zconf.y   |  2 +-
>>>  19 files changed, 158 insertions(+), 180 deletions(-)
>>>  create mode 100644 scripts/kconfig/env.c
>>>
>>> diff --git a/Documentation/kbuild/kconfig-language.txt 
>>> b/Documentation/kbuild/kconfig-language.txt
>>> index f5b9493..0e966e8 100644
>>> --- a/Documentat

Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax

[Ulf Magnusson]

On Thu, Mar 29, 2018 at 4:56 AM, Ulf Magnusson  wrote:
> On Thu, Mar 29, 2018 at 4:19 AM, Ulf Magnusson  wrote:
>> I've been kinda busy lately, so that's why I disappeared.
>>
>> I'll try to go over this patchset in more detail over the weekend.
>>
>> On Tue, Mar 27, 2018 at 7:29 AM, 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',
>>> '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 
>>> ---
>>>
>>> I tested all 'make *config' for arch architectures.
>>> I confirmed this commit still produced the same result
>>> (by my kconfig test tool).
>>>
>>>
>>> Changes in v2:
>>>   - Move the string expansion to the lexer phase.
>>>   - Split environment helpers to env.c
>>>
>>>  Documentation/kbuild/kconfig-language.txt |  8 ---
>>>  Kconfig   |  4 --
>>>  Makefile  |  3 +-
>>>  arch/sh/Kconfig   |  4 +-
>>>  arch/sparc/Kconfig|  4 +-
>>>  arch/tile/Kconfig |  2 +-
>>>  arch/um/Kconfig.common|  4 --
>>>  arch/x86/Kconfig  |  4 +-
>>>  arch/x86/um/Kconfig   |  4 +-
>>>  init/Kconfig  | 10 +---
>>>  scripts/kconfig/confdata.c| 31 +-
>>>  scripts/kconfig/env.c | 95 
>>> +++
>>>  scripts/kconfig/kconf_id.c|  1 -
>>>  scripts/kconfig/lkc.h |  8 +--
>>>  scripts/kconfig/menu.c|  3 -
>>>  scripts/kconfig/symbol.c  | 56 --
>>>  scripts/kconfig/util.c| 75 
>>>  scripts/kconfig/zconf.l   | 20 ++-
>>>  scripts/kconfig/zconf.y   |  2 +-
>>>  19 files changed, 158 insertions(+), 180 deletions(-)
>>>  create mode 100644 scripts/kconfig/env.c
>>>
>>> diff --git a/Documentation/kbuild/kconfig-language.txt 
>>> b/Documentation/kbuild/kconfig-language.txt
>>> index f5b9493..0e966e8 100644
>>> --- a/Documentation/kbuild/kconfig-language.txt
>>> +++ b/Documentation/kbuild/kconfig-language.txt
>>> @@ -198,14 +198

Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax

[Ulf Magnusson]

On Thu, Mar 29, 2018 at 4:19 AM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> I've been kinda busy lately, so that's why I disappeared.
>
> I'll try to go over this patchset in more detail over the weekend.
>
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
> <yamada.masah...@socionext.com> 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.masah...@socionext.com>
>> ---
>>
>> I tested all 'make *config' for arch architectures.
>> I confirmed this commit still produced the same result
>> (by my kconfig test tool).
>>
>>
>> Changes in v2:
>>   - Move the string expansion to the lexer phase.
>>   - Split environment helpers to env.c
>>
>>  Documentation/kbuild/kconfig-language.txt |  8 ---
>>  Kconfig   |  4 --
>>  Makefile  |  3 +-
>>  arch/sh/Kconfig   |  4 +-
>>  arch/sparc/Kconfig|  4 +-
>>  arch/tile/Kconfig |  2 +-
>>  arch/um/Kconfig.common|  4 --
>>  arch/x86/Kconfig  |  4 +-
>>  arch/x86/um/Kconfig   |  4 +-
>>  init/Kconfig  | 10 +---
>>  scripts/kconfig/confdata.c| 31 +-
>>  scripts/kconfig/env.c | 95 
>> +++
>>  scripts/kconfig/kconf_id.c|  1 -
>>  scripts/kconfig/lkc.h |  8 +--
>>  scripts/kconfig/menu.c|  3 -
>>  scripts/kconfig/symbol.c  | 56 --
>>  scripts/kconfig/util.c| 75 
>>  scripts/kconfig/zconf.l   | 20 ++-
>>  scripts/kconfig/zconf.y   |  2 +-
>>  19 files changed, 158 insertions(+), 180 deletions(-)
>>  create mode 100644 scripts/kconfig/env.c
>>
>> diff --git a/Documentation/kbuild/kconfig-language.txt 
>> b/Documentation/kbuild/kconfig-language.txt
>> index f5b9493..0e966e8 100644
>> --- a/Documentation/kbuild/kconfig-language.txt
>> +++ b/Documentation/kbuild/kconfig-language.txt
>> @@ -198,14 +198,6 @@ applicable everywhere (see syntax).
>>  enables the third modular state for all config symbols.
>>  At most one symbol may have the "modules" option set.
>>
>> -  - "env"=
>> -This imports the environment variable into Kconfig. It behaves like
>> -a default, except that the value comes from the e

Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax

[Ulf Magnusson]

On Thu, Mar 29, 2018 at 4:19 AM, Ulf Magnusson  wrote:
> I've been kinda busy lately, so that's why I disappeared.
>
> I'll try to go over this patchset in more detail over the weekend.
>
> On Tue, Mar 27, 2018 at 7:29 AM, 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',
>> '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 
>> ---
>>
>> I tested all 'make *config' for arch architectures.
>> I confirmed this commit still produced the same result
>> (by my kconfig test tool).
>>
>>
>> Changes in v2:
>>   - Move the string expansion to the lexer phase.
>>   - Split environment helpers to env.c
>>
>>  Documentation/kbuild/kconfig-language.txt |  8 ---
>>  Kconfig   |  4 --
>>  Makefile  |  3 +-
>>  arch/sh/Kconfig   |  4 +-
>>  arch/sparc/Kconfig|  4 +-
>>  arch/tile/Kconfig |  2 +-
>>  arch/um/Kconfig.common|  4 --
>>  arch/x86/Kconfig  |  4 +-
>>  arch/x86/um/Kconfig   |  4 +-
>>  init/Kconfig  | 10 +---
>>  scripts/kconfig/confdata.c| 31 +-
>>  scripts/kconfig/env.c | 95 
>> +++
>>  scripts/kconfig/kconf_id.c|  1 -
>>  scripts/kconfig/lkc.h |  8 +--
>>  scripts/kconfig/menu.c|  3 -
>>  scripts/kconfig/symbol.c  | 56 --
>>  scripts/kconfig/util.c| 75 
>>  scripts/kconfig/zconf.l   | 20 ++-
>>  scripts/kconfig/zconf.y   |  2 +-
>>  19 files changed, 158 insertions(+), 180 deletions(-)
>>  create mode 100644 scripts/kconfig/env.c
>>
>> diff --git a/Documentation/kbuild/kconfig-language.txt 
>> b/Documentation/kbuild/kconfig-language.txt
>> index f5b9493..0e966e8 100644
>> --- a/Documentation/kbuild/kconfig-language.txt
>> +++ b/Documentation/kbuild/kconfig-language.txt
>> @@ -198,14 +198,6 @@ applicable everywhere (see syntax).
>>  enables the third modular state for all config symbols.
>>  At most one symbol may have the "modules" option set.
>>
>> -  - "env"=
>> -This imports the environment variable into Kconfig. It behaves like
>> -a default, except that the value comes from the environment, this
>> -also means that the behaviour when mixing it with normal default

Re: [PATCH v2 07/21] kconfig: add function support and implement 'shell' function

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
 wrote:
> This commit adds a new concept 'function' to do more text processing
> in Kconfig.
>
> A function call looks like this:
>
>   $(function arg1, arg2, arg3, ...)
>
> (Actually, this syntax was inspired by make.)
>
> Real examples will look like this:
>
>   $(shell echo hello world)
>   $(cc-option -fstackprotector)
>
> This commit adds the basic infrastructure to add, delete, evaluate
> functions, and also the first built-in function $(shell ...).  This
> accepts a single command to execute.  It returns the standard output
> from it.
>
> [Example code]
>
>   config HELLO
>   string
>   default "$(shell echo hello world)"
>
>   config Y
>   def_bool $(shell echo y)
>
> [Result]
>
>   $ make -s alldefconfig && tail -n 2 .config
>   CONFIG_HELLO="hello world"
>   CONFIG_Y=y
>
> Caveat:
> Like environments, functions are expanded in the lexer.  You cannot
> pass symbols to function arguments.  This is a limitation to simplify
> the implementation.  I want to avoid the dynamic function evaluation,
> which would introduce much more complexity.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Reminder for myself:
> Update Documentation/kbuild/kconfig-language.txt
>
>
> Changes in v2:
>   - Use 'shell' for getting stdout from the comment.
> It was 'shell-stdout' in the previous version.
>   - Symplify the implementation since the expansion has been moved to
> lexer.
>
>  scripts/kconfig/function.c  | 170 
> 
>  scripts/kconfig/lkc_proto.h |   5 ++
>  scripts/kconfig/util.c  |  46 +---
>  scripts/kconfig/zconf.y |   9 +++
>  4 files changed, 222 insertions(+), 8 deletions(-)
>  create mode 100644 scripts/kconfig/function.c
>

The gotcha from 04/21 ("kconfig: reference environments directly and
remove 'option env=' syntax") applies here too. For example, the
following will work:

config A
bool "A"
default $(shell echo "B && C")

Some people might argue that that's a feature (I sense a mess down the
road if people start depending on it), but just in case you hadn't
thought of it.

Similarly, the following will only work as expected if 'cmd' outputs
the name of an undefined Kconfig symbol:

config A
string
default $(shell cmd)

You could argue that people should add quotes there though (though
that's broken at the moment if the output from 'cmd' includes a
quote).

Quotes in Kconfig speak just mean "constant value". Problem is it's
undocumented, and no one would intuitively expect it.

Cheers,
Ulf

Re: [PATCH v2 07/21] kconfig: add function support and implement 'shell' function

[Ulf Magnusson]

On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
 wrote:
> This commit adds a new concept 'function' to do more text processing
> in Kconfig.
>
> A function call looks like this:
>
>   $(function arg1, arg2, arg3, ...)
>
> (Actually, this syntax was inspired by make.)
>
> Real examples will look like this:
>
>   $(shell echo hello world)
>   $(cc-option -fstackprotector)
>
> This commit adds the basic infrastructure to add, delete, evaluate
> functions, and also the first built-in function $(shell ...).  This
> accepts a single command to execute.  It returns the standard output
> from it.
>
> [Example code]
>
>   config HELLO
>   string
>   default "$(shell echo hello world)"
>
>   config Y
>   def_bool $(shell echo y)
>
> [Result]
>
>   $ make -s alldefconfig && tail -n 2 .config
>   CONFIG_HELLO="hello world"
>   CONFIG_Y=y
>
> Caveat:
> Like environments, functions are expanded in the lexer.  You cannot
> pass symbols to function arguments.  This is a limitation to simplify
> the implementation.  I want to avoid the dynamic function evaluation,
> which would introduce much more complexity.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Reminder for myself:
> Update Documentation/kbuild/kconfig-language.txt
>
>
> Changes in v2:
>   - Use 'shell' for getting stdout from the comment.
> It was 'shell-stdout' in the previous version.
>   - Symplify the implementation since the expansion has been moved to
> lexer.
>
>  scripts/kconfig/function.c  | 170 
> 
>  scripts/kconfig/lkc_proto.h |   5 ++
>  scripts/kconfig/util.c  |  46 +---
>  scripts/kconfig/zconf.y |   9 +++
>  4 files changed, 222 insertions(+), 8 deletions(-)
>  create mode 100644 scripts/kconfig/function.c
>

The gotcha from 04/21 ("kconfig: reference environments directly and
remove 'option env=' syntax") applies here too. For example, the
following will work:

config A
bool "A"
default $(shell echo "B && C")

Some people might argue that that's a feature (I sense a mess down the
road if people start depending on it), but just in case you hadn't
thought of it.

Similarly, the following will only work as expected if 'cmd' outputs
the name of an undefined Kconfig symbol:

config A
string
default $(shell cmd)

You could argue that people should add quotes there though (though
that's broken at the moment if the output from 'cmd' includes a
quote).

Quotes in Kconfig speak just mean "constant value". Problem is it's
undocumented, and no one would intuitively expect it.

Cheers,
Ulf

Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax

[Ulf Magnusson]

I've been kinda busy lately, so that's why I disappeared.

I'll try to go over this patchset in more detail over the weekend.

On Tue, Mar 27, 2018 at 7:29 AM, 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',
> '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 
> ---
>
> I tested all 'make *config' for arch architectures.
> I confirmed this commit still produced the same result
> (by my kconfig test tool).
>
>
> Changes in v2:
>   - Move the string expansion to the lexer phase.
>   - Split environment helpers to env.c
>
>  Documentation/kbuild/kconfig-language.txt |  8 ---
>  Kconfig   |  4 --
>  Makefile  |  3 +-
>  arch/sh/Kconfig   |  4 +-
>  arch/sparc/Kconfig|  4 +-
>  arch/tile/Kconfig |  2 +-
>  arch/um/Kconfig.common|  4 --
>  arch/x86/Kconfig  |  4 +-
>  arch/x86/um/Kconfig   |  4 +-
>  init/Kconfig  | 10 +---
>  scripts/kconfig/confdata.c| 31 +-
>  scripts/kconfig/env.c | 95 
> +++
>  scripts/kconfig/kconf_id.c|  1 -
>  scripts/kconfig/lkc.h |  8 +--
>  scripts/kconfig/menu.c|  3 -
>  scripts/kconfig/symbol.c  | 56 --
>  scripts/kconfig/util.c| 75 
>  scripts/kconfig/zconf.l   | 20 ++-
>  scripts/kconfig/zconf.y   |  2 +-
>  19 files changed, 158 insertions(+), 180 deletions(-)
>  create mode 100644 scripts/kconfig/env.c
>
> diff --git a/Documentation/kbuild/kconfig-language.txt 
> b/Documentation/kbuild/kconfig-language.txt
> index f5b9493..0e966e8 100644
> --- a/Documentation/kbuild/kconfig-language.txt
> +++ b/Documentation/kbuild/kconfig-language.txt
> @@ -198,14 +198,6 @@ applicable everywhere (see syntax).
>  enables the third modular state for all config symbols.
>  At most one symbol may have the "modules" option set.
>
> -  - "env"=
> -This imports the environment variable into Kconfig. It behaves like
> -a default, except that the value comes from the environment, this
> -also means that the behaviour when mixing it with normal defaults is
> -undefined at this point. The symbol is currently not exported back
> -to the build environment (if this is desired, it can be done via
> -another symbol).
> -
>- "allnoconfig_y"
>  This declares the symbol as one that should have the value y when
>  using "allnoconfig". Used for symbols that hide other symbols.
> diff --git a/Kconfig b/Kconfig
> index 8c4c1cb..e6ece5b 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -5,8 +5,4 @@
>  #
>  mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"
>
> -config SRCARCH
> -   string
> -   option env="SRCARCH"
> -
>  source "arch/$SRCARCH/Kconfig"
> diff --git a/Makefile b/Makefile
> index 5c395ed..4ae1486 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -284,7 +284,8 @@ include scripts/Kbuild.include
>  # Read 

Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax

[Ulf Magnusson]

I've been kinda busy lately, so that's why I disappeared.

I'll try to go over this patchset in more detail over the weekend.

On Tue, Mar 27, 2018 at 7:29 AM, 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',
> '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 
> ---
>
> I tested all 'make *config' for arch architectures.
> I confirmed this commit still produced the same result
> (by my kconfig test tool).
>
>
> Changes in v2:
>   - Move the string expansion to the lexer phase.
>   - Split environment helpers to env.c
>
>  Documentation/kbuild/kconfig-language.txt |  8 ---
>  Kconfig   |  4 --
>  Makefile  |  3 +-
>  arch/sh/Kconfig   |  4 +-
>  arch/sparc/Kconfig|  4 +-
>  arch/tile/Kconfig |  2 +-
>  arch/um/Kconfig.common|  4 --
>  arch/x86/Kconfig  |  4 +-
>  arch/x86/um/Kconfig   |  4 +-
>  init/Kconfig  | 10 +---
>  scripts/kconfig/confdata.c| 31 +-
>  scripts/kconfig/env.c | 95 
> +++
>  scripts/kconfig/kconf_id.c|  1 -
>  scripts/kconfig/lkc.h |  8 +--
>  scripts/kconfig/menu.c|  3 -
>  scripts/kconfig/symbol.c  | 56 --
>  scripts/kconfig/util.c| 75 
>  scripts/kconfig/zconf.l   | 20 ++-
>  scripts/kconfig/zconf.y   |  2 +-
>  19 files changed, 158 insertions(+), 180 deletions(-)
>  create mode 100644 scripts/kconfig/env.c
>
> diff --git a/Documentation/kbuild/kconfig-language.txt 
> b/Documentation/kbuild/kconfig-language.txt
> index f5b9493..0e966e8 100644
> --- a/Documentation/kbuild/kconfig-language.txt
> +++ b/Documentation/kbuild/kconfig-language.txt
> @@ -198,14 +198,6 @@ applicable everywhere (see syntax).
>  enables the third modular state for all config symbols.
>  At most one symbol may have the "modules" option set.
>
> -  - "env"=
> -This imports the environment variable into Kconfig. It behaves like
> -a default, except that the value comes from the environment, this
> -also means that the behaviour when mixing it with normal defaults is
> -undefined at this point. The symbol is currently not exported back
> -to the build environment (if this is desired, it can be done via
> -another symbol).
> -
>- "allnoconfig_y"
>  This declares the symbol as one that should have the value y when
>  using "allnoconfig". Used for symbols that hide other symbols.
> diff --git a/Kconfig b/Kconfig
> index 8c4c1cb..e6ece5b 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -5,8 +5,4 @@
>  #
>  mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"
>
> -config SRCARCH
> -   string
> -   option env="SRCARCH"
> -
>  source "arch/$SRCARCH/Kconfig"
> diff --git a/Makefile b/Makefile
> index 5c395ed..4ae1486 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -284,7 +284,8 @@ include scripts/Kbuild.include
>  # Read KERNELRELEASE from include/config/kernel.release (if it exists)

Re: [PATCH 0/3] Improve and extend checkpatch.pl Kconfig help text checks

[Ulf Magnusson]

On Sat, Feb 24, 2018 at 2:53 PM, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> 2018-02-23 10:30 GMT+09:00 Ulf Magnusson <ulfali...@gmail.com>:
>> On Fri, Feb 16, 2018 at 10:14 PM, Joe Perches <j...@perches.com> wrote:
>>> On Fri, 2018-02-16 at 21:22 +0100, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> This patchset contains some improvements for the Kconfig help text check in
>>>> scripts/checkconfig.pl:
>>>
>>> Seems sensible enough to me.
>>> Signed-off-by: Joe Perches <j...@perches.com>
>>
>> Will you be taking this in yourself?
>>
>> (Adding Masahiro on CC -- forgot when I sent the patchset.)
>>
>> Cheers,
>> Ulf
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> I am not a perl expert, but I have no objection for this series.
>
>
> Thanks!
>
>
>
>
> --
> Best Regards
> Masahiro Yamada

*Bump*

Re: [PATCH 0/3] Improve and extend checkpatch.pl Kconfig help text checks

[Ulf Magnusson]

On Sat, Feb 24, 2018 at 2:53 PM, Masahiro Yamada
 wrote:
> 2018-02-23 10:30 GMT+09:00 Ulf Magnusson :
>> On Fri, Feb 16, 2018 at 10:14 PM, Joe Perches  wrote:
>>> On Fri, 2018-02-16 at 21:22 +0100, Ulf Magnusson wrote:
>>>> Hello,
>>>>
>>>> This patchset contains some improvements for the Kconfig help text check in
>>>> scripts/checkconfig.pl:
>>>
>>> Seems sensible enough to me.
>>> Signed-off-by: Joe Perches 
>>
>> Will you be taking this in yourself?
>>
>> (Adding Masahiro on CC -- forgot when I sent the patchset.)
>>
>> Cheers,
>> Ulf
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> I am not a perl expert, but I have no objection for this series.
>
>
> Thanks!
>
>
>
>
> --
> Best Regards
> Masahiro Yamada

*Bump*

Re: [PATCH] scripts/kconfig: replace single character strcat() appends

[Ulf Magnusson]

On Sat, Mar 3, 2018 at 7:14 PM, Ulf Magnusson <ulfali...@gmail.com> wrote:
> On Sat, Mar 3, 2018 at 12:12 AM, Joey Pabalinas <joeypabali...@gmail.com> 
> wrote:
>> On Fri, Mar 02, 2018 at 02:44:53PM +0100, Ulf Magnusson wrote:
>>> Not sure this is an improvement. Zeroing the bytes after the initial
>>> null terminator is redundant, and the explicit '\0' makes it clearer to
>>> me what's going on.
>>
>> Yes, I agree with you, that is definitely quite true. This along with
>> the other comments you made me want to rethink this a little bit.
>>
>> On Fri, Mar 02, 2018 at 02:44:53PM +0100, Ulf Magnusson wrote:
>>> I like the approach, but I wonder if we can take it a bit further.
>>> Here's what I'd do:
>>>
>>>   1. Rename the 'in' parameter to 's'.
>>>   2. Rename 'p' to 'in'.
>>>   3. Rename 'end' to 'out'
>>>
>>> At that point, you're reading from 'in' and writing to 'out', which
>>> seems pretty nice and readable.
>>>
>>> This code is pretty cold by the way, so it wouldn't matter for
>>> performance. GCC knows how functions like strcat() work too, and uses
>>> that to optimize (see
>>> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html).
>>>
>>> I'm all for trying to make Kconfig's code neater though.
>>
>> Since this code is pretty cold (completely agree with you there), I
>> think it would actually be much more useful to rework my patch to
>> have a more style-centric approach rather than an optimization-centric
>> one; this code would definitely benefit from being neater.
>
> I actually prefer the memcpy() version for style reasons, even though
> it might've looked like an optimization:
>
> With strncat(), the result string is written via both 'res' and 'end'.
> With memcpy(), it's only written via the 'end'. That seems less
> twisty.
>
> Maybe this is outside the scope of the original patch, but while we're here. 
> :)
>
>>
>> Some useful changes would be to rename of the _atrociously_ short
>> identifiers like p and l.
>
> Yeah, 'l' in particular isn't the best name, IMO ('len' is both short
> and explicit, and won't be confused for 1). 'p' can be fine if it's
> obvious in context (bit dubious here), but 'in' and 'out' (for 'end')
> would be more informative.

Another alternative: src/dst

>
> 's' is clear from convention to me. In general, I fully agree that you
> should avoid hard-to-guess names though.
>
>>
>> Anyway I'll give that link a read over and try and make a V2 later
>> on today.
>>
>> Appreciate the feedback, thanks for the comments!
>>
>> --
>> Cheers,
>> Joey Pabalinas
>
> Cheers,
> Ulf

Cheers,
Ulf

Re: [PATCH] scripts/kconfig: replace single character strcat() appends

[Ulf Magnusson]

On Sat, Mar 3, 2018 at 7:14 PM, Ulf Magnusson  wrote:
> On Sat, Mar 3, 2018 at 12:12 AM, Joey Pabalinas  
> wrote:
>> On Fri, Mar 02, 2018 at 02:44:53PM +0100, Ulf Magnusson wrote:
>>> Not sure this is an improvement. Zeroing the bytes after the initial
>>> null terminator is redundant, and the explicit '\0' makes it clearer to
>>> me what's going on.
>>
>> Yes, I agree with you, that is definitely quite true. This along with
>> the other comments you made me want to rethink this a little bit.
>>
>> On Fri, Mar 02, 2018 at 02:44:53PM +0100, Ulf Magnusson wrote:
>>> I like the approach, but I wonder if we can take it a bit further.
>>> Here's what I'd do:
>>>
>>>   1. Rename the 'in' parameter to 's'.
>>>   2. Rename 'p' to 'in'.
>>>   3. Rename 'end' to 'out'
>>>
>>> At that point, you're reading from 'in' and writing to 'out', which
>>> seems pretty nice and readable.
>>>
>>> This code is pretty cold by the way, so it wouldn't matter for
>>> performance. GCC knows how functions like strcat() work too, and uses
>>> that to optimize (see
>>> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html).
>>>
>>> I'm all for trying to make Kconfig's code neater though.
>>
>> Since this code is pretty cold (completely agree with you there), I
>> think it would actually be much more useful to rework my patch to
>> have a more style-centric approach rather than an optimization-centric
>> one; this code would definitely benefit from being neater.
>
> I actually prefer the memcpy() version for style reasons, even though
> it might've looked like an optimization:
>
> With strncat(), the result string is written via both 'res' and 'end'.
> With memcpy(), it's only written via the 'end'. That seems less
> twisty.
>
> Maybe this is outside the scope of the original patch, but while we're here. 
> :)
>
>>
>> Some useful changes would be to rename of the _atrociously_ short
>> identifiers like p and l.
>
> Yeah, 'l' in particular isn't the best name, IMO ('len' is both short
> and explicit, and won't be confused for 1). 'p' can be fine if it's
> obvious in context (bit dubious here), but 'in' and 'out' (for 'end')
> would be more informative.

Another alternative: src/dst

>
> 's' is clear from convention to me. In general, I fully agree that you
> should avoid hard-to-guess names though.
>
>>
>> Anyway I'll give that link a read over and try and make a V2 later
>> on today.
>>
>> Appreciate the feedback, thanks for the comments!
>>
>> --
>> Cheers,
>> Joey Pabalinas
>
> Cheers,
> Ulf

Cheers,
Ulf

Re: [PATCH] scripts/kconfig: replace single character strcat() appends

[Ulf Magnusson]

On Sat, Mar 3, 2018 at 12:12 AM, Joey Pabalinas <joeypabali...@gmail.com> wrote:
> On Fri, Mar 02, 2018 at 02:44:53PM +0100, Ulf Magnusson wrote:
>> Not sure this is an improvement. Zeroing the bytes after the initial
>> null terminator is redundant, and the explicit '\0' makes it clearer to
>> me what's going on.
>
> Yes, I agree with you, that is definitely quite true. This along with
> the other comments you made me want to rethink this a little bit.
>
> On Fri, Mar 02, 2018 at 02:44:53PM +0100, Ulf Magnusson wrote:
>> I like the approach, but I wonder if we can take it a bit further.
>> Here's what I'd do:
>>
>>   1. Rename the 'in' parameter to 's'.
>>   2. Rename 'p' to 'in'.
>>   3. Rename 'end' to 'out'
>>
>> At that point, you're reading from 'in' and writing to 'out', which
>> seems pretty nice and readable.
>>
>> This code is pretty cold by the way, so it wouldn't matter for
>> performance. GCC knows how functions like strcat() work too, and uses
>> that to optimize (see
>> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html).
>>
>> I'm all for trying to make Kconfig's code neater though.
>
> Since this code is pretty cold (completely agree with you there), I
> think it would actually be much more useful to rework my patch to
> have a more style-centric approach rather than an optimization-centric
> one; this code would definitely benefit from being neater.

I actually prefer the memcpy() version for style reasons, even though
it might've looked like an optimization:

With strncat(), the result string is written via both 'res' and 'end'.
With memcpy(), it's only written via the 'end'. That seems less
twisty.

Maybe this is outside the scope of the original patch, but while we're here. :)

>
> Some useful changes would be to rename of the _atrociously_ short
> identifiers like p and l.

Yeah, 'l' in particular isn't the best name, IMO ('len' is both short
and explicit, and won't be confused for 1). 'p' can be fine if it's
obvious in context (bit dubious here), but 'in' and 'out' (for 'end')
would be more informative.

's' is clear from convention to me. In general, I fully agree that you
should avoid hard-to-guess names though.

>
> Anyway I'll give that link a read over and try and make a V2 later
> on today.
>
> Appreciate the feedback, thanks for the comments!
>
> --
> Cheers,
> Joey Pabalinas

Cheers,
Ulf