linux.git/scripts/kconfig, branch v4.19.56

kconfig/[mn]conf: handle backspace (^H) key

2019-05-04T07:20:22+00:00

[ Upstream commit 9c38f1f044080392603c497ecca4d7d09876ff99 ]

Backspace is not working on some terminal emulators which do not send the
key code defined by terminfo. Terminals either send '^H' (8) or '^?' (127).
But currently only '^?' is handled. Let's also handle '^H' for those
terminals.

Signed-off-by: Changbin Du 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin (Microsoft)

kconfig: fix memory leak when EOF is encountered in quotation

2019-01-26T08:32:39+00:00

[ Upstream commit fbac5977d81cb2b2b7e37b11c459055d9585273c ]

An unterminated string literal followed by new line is passed to the
parser (with "multi-line strings not supported" warning shown), then
handled properly there.

On the other hand, an unterminated string literal at end of file is
never passed to the parser, then results in memory leak.

[Test Code]

  ----------(Kconfig begin)----------
  source "Kconfig.inc"

  config A
          bool "a"
  -----------(Kconfig end)-----------

  --------(Kconfig.inc begin)--------
  config B
          bool "b\No new line at end of file
  ---------(Kconfig.inc end)---------

[Summary from Valgrind]

  Before the fix:

    LEAK SUMMARY:
       definitely lost: 16 bytes in 1 blocks
       ...

  After the fix:

    LEAK SUMMARY:
       definitely lost: 0 bytes in 0 blocks
       ...

Eliminate the memory leak path by handling this case. Of course, such
a Kconfig file is wrong already, so I will add an error message later.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin

kconfig: fix file name and line number of warn_ignored_character()

2019-01-26T08:32:39+00:00

[ Upstream commit 77c1c0fa8b1477c5799bdad65026ea5ff676da44 ]

Currently, warn_ignore_character() displays invalid file name and
line number.

The lexer should use current_file->name and yylineno, while the parser
should use zconf_curname() and zconf_lineno().

This difference comes from that the lexer is always going ahead
of the parser. The parser needs to look ahead one token to make a
shift/reduce decision, so the lexer is requested to scan more text
from the input file.

This commit fixes the warning message from warn_ignored_character().

[Test Code]

  ----(Kconfig begin)----
  /
  -----(Kconfig end)-----

[Output]

  Before the fix:

  :0:warning: ignoring unsupported character '/'

  After the fix:

  Kconfig:1:warning: ignoring unsupported character '/'

Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin

kconfig: do not require pkg-config on make {menu,n}config

2018-09-02T17:13:48+00:00

Meelis Roos reported a {menu,n}config regression:
 "I have libncurses devel package installed in the default system
  location (as do 99%+ on actual developers probably) and in this
  case, pkg-config is useless.  pkg-config is needed only when
  libraries and headers are installed in non-default locations but
  it is bad to require installation of pkg-config on all the machines
  where make menuconfig would be possibly run."

For {menu,n}config, do not use pkg-config if it is not installed.
For {g,x}config, keep checking pkg-config since we really rely on it
for finding the installation paths of the required packages.

Fixes: 4ab3b80159d4 ("kconfig: check for pkg-config on make {menu,n,g,x}config")
Reported-by: Meelis Roos 
Signed-off-by: Masahiro Yamada 
Tested-by: Meelis Roos 
Tested-by: Randy Dunlap

kconfig: remove a spurious self-assignment

2018-08-31T16:21:42+00:00

The self assignment was probably introduced by an automated code
refactoring in
commit 694c49a7c01c ("kconfig: drop localization support").

The issue was identified by a self-assign warning when running
make menuconfig with clang.

Fixes: 694c49a7c01c ("kconfig: drop localization support")
Signed-off-by: Lukas Bulwahn 
Signed-off-by: Masahiro Yamada

kconfig: suppress "configuration written to .config" for syncconfig

2018-08-22T14:21:41+00:00

The top-level Makefile invokes "make syncconfig" when necessary.
Then, Kconfig displays the following message when .config is updated.

  #
  # configuration written to .config
  #

It is distracting because "make syncconfig" happens during the build
stage, and does nothing important in most cases.

Suggested-by: Linus Torvalds 
Signed-off-by: Masahiro Yamada

kconfig: fix "Can't open ..." in parallel build

2018-08-22T14:21:41+00:00

If you run "make menuconfig" or "make nconfig" with -j option in a
fresh source tree, you will see several "Can't open ..." messages:

  $ make -j8 menuconfig
    HOSTCC  scripts/basic/fixdep
    YACC    scripts/kconfig/zconf.tab.c
    LEX     scripts/kconfig/zconf.lex.c
  /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg
  /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg
  /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg
  /bin/sh: 1: .:   HOSTCC  scripts/kconfig/lxdialog/checklist.o
  Can't open scripts/kconfig/.mconf-cfg
  /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg
  /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg
  /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg
    HOSTCC  scripts/kconfig/lxdialog/inputbox.o
  /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg
  /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg
  /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg
    UPD     scripts/kconfig/.mconf-cfg
  /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg
    HOSTCC  scripts/kconfig/lxdialog/menubox.o
    HOSTCC  scripts/kconfig/lxdialog/textbox.o
    HOSTCC  scripts/kconfig/lxdialog/util.o
    HOSTCC  scripts/kconfig/lxdialog/yesno.o
    HOSTCC  scripts/kconfig/mconf.o
    HOSTCC  scripts/kconfig/zconf.tab.o
    HOSTLD  scripts/kconfig/mconf

Correct dependencies to fix this problem.

Fixes: 1c5af5cf9308 ("kconfig: refactor ncurses package checks for building mconf and nconf")
Cc: linux-stable  # v4.18
Reported-by: Borislav Petkov 
Signed-off-by: Masahiro Yamada 
Tested-by: Borislav Petkov

kconfig: improve the recursive dependency report

2018-08-22T14:21:39+00:00

This commit improves the messages of the recursive dependency.
Currently, sym->dir_dep.expr is not checked.  Hence, any dependency
in property visibility is regarded as the dependency of the symbol.

[Test Code 1]

  config A
          bool "a"
          depends on B

  config B
          bool "b"
          depends on A

[Test Code 2]

  config A
          bool "a" if B

  config B
          bool "b"
          depends on A

For both cases above, the same message is displayed:

        symbol B depends on A
        symbol A depends on B

This commit changes the message for the latter, like this:

        symbol B depends on A
        symbol A prompt is visible depending on B

Also, 'select' and 'imply' are distinguished.

Signed-off-by: Masahiro Yamada 
Tested-by: Dirk Gouders

kconfig: report recursive dependency involving 'imply'

2018-08-22T14:21:39+00:00

Currently, Kconfig does not complain about the recursive dependency
where 'imply' keywords are involved.

[Test Code]

  config A
          bool "a"

  config B
          bool "b"
          imply A
          depends on A

In the code above, Kconfig cannot calculate the symbol values correctly
due to the circular dependency.  For example, allyesconfig followed by
syncconfig results in an odd behavior because CONFIG_B becomes visible
in syncconfig.

  $ make allyesconfig
  scripts/kconfig/conf  --allyesconfig Kconfig
  #
  # configuration written to .config
  #
  $ cat .config
  #
  # Automatically generated file; DO NOT EDIT.
  # Main menu
  #
  CONFIG_A=y
  $ make syncconfig
  scripts/kconfig/conf  --syncconfig Kconfig
  *
  * Restart config...
  *
  *
  * Main menu
  *
  a (A) [Y/n/?] y
    b (B) [N/y/?] (NEW)

To detect this correctly, sym_check_expr_deps() should recurse to
not only sym->rev_dep.expr but also sym->implied.expr .

At this moment, sym_check_print_recursive() cannot distinguish
'select' and 'imply' since it does not know the precise context
where the recursive dependency has been hit.  This will be solved
by the next commit.

In fact, even the document and the unit-test are confused.  Using
'imply' does not solve recursive dependency since 'imply' addresses
the unmet direct dependency, which 'select' could cause.

Signed-off-by: Masahiro Yamada 
Tested-by: Dirk Gouders

kconfig: error out when seeing recursive dependency

2018-08-22T14:21:38+00:00

Originally, recursive dependency was a fatal error for Kconfig
because Kconfig cannot compute symbol values in such a situation.

Commit d595cea62403 ("kconfig: print more info when we see a recursive
dependency") changed it to a warning, which I guess was not intentional.

Get it back to an error again.

Also, rename the unit test directory "warn_recursive_dep" to
"err_recursive_dep" so that it matches to the behavior.

Signed-off-by: Masahiro Yamada 
Tested-by: Dirk Gouders