[ANNOUNCE] Kconfiglib GUI menuconfig
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
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
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
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
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='
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='
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
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
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
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
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
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
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
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
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
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
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
On Sun, May 20, 2018 at 4:50 PM, Sam Ravnborgwrote: > 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
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='
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='
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='
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='
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
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
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='
On Thu, May 17, 2018 at 8:16 AM, Masahiro Yamadawrote: > 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='
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
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
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
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
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
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
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
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
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
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
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
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
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
On Mon, May 14, 2018 at 6:58 PM, Pavel Machekwrote: > 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
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
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
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
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 Dunlapwrote: > 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
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
On Thu, May 3, 2018 at 10:28 PM, Randy Dunlapwrote: > 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
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
On Thu, May 3, 2018 at 10:31 PM, Randy Dunlapwrote: > 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamadawrote: > 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
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
On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamadawrote: > 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
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
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
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
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
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
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
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
On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamadawrote: > 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
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
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
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
On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamadawrote: > 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
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()
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()
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()
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()
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
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
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
Here's a more in-depth review: On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamadawrote: > 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
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
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
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
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
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
On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamadawrote: > 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
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
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 Yamadawrote: > 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
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
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
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
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
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
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