26 Jan, 2019

2 commits

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

    Masahiro Yamada
     
  • [ 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

    Masahiro Yamada
     

03 Sep, 2018

1 commit

  • 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

    Masahiro Yamada
     

01 Sep, 2018

1 commit

  • 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

    Lukas Bulwahn
     

22 Aug, 2018

6 commits

  • 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

    Masahiro Yamada
     
  • 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

    Masahiro Yamada
     
  • 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

    Masahiro Yamada
     
  • 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

    Masahiro Yamada
     
  • 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

    Masahiro Yamada
     
  • Add build-only targets for build_menuconfig, build_nconfig,
    build_xconfig, and build_gconfig.
    (targets must end in "config" to qualify in top-level Makefile)

    This allows these target to be built without execution (e.g., to
    look for errors or warnings) and/or to be built and checked by sparse.

    Signed-off-by: Randy Dunlap
    Signed-off-by: Masahiro Yamada

    Randy Dunlap
     

16 Aug, 2018

1 commit

  • Pull Kconfig updates from Masahiro Yamada:

    - show clearer error messages where pkg-config is needed, but not
    installed

    - rename SYMBOL_AUTO to SYMBOL_NO_WRITE to reflect its semantics

    - create all necessary directories by Kconfig tool itself instead of
    Makefile

    - update the .config unconditionally when syncconfig is invoked

    - use 'include' directive instead of '-include' where
    include/config/{auto,tristate}.conf is mandatory

    - do not try to update the .config when running install targets

    - add .DELETE_ON_ERROR to delete partially updated files

    - misc cleanups and fixes

    * tag 'kconfig-v4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
    kconfig: remove P_ENV property type
    kconfig: remove unused sym_get_env_prop() function
    kconfig: fix the rule of mainmenu_stmt symbol
    init/Kconfig: Use short unix-style option instead of --longname
    Kbuild: Makefile.modbuiltin: include auto.conf and tristate.conf mandatory
    kbuild: remove auto.conf from prerequisite of phony targets
    kbuild: do not update config for 'make kernelrelease'
    kbuild: do not update config when running install targets
    kbuild: add .DELETE_ON_ERROR special target
    kbuild: use 'include' directive to load auto.conf from top Makefile
    kconfig: allow all config targets to write auto.conf if missing
    kconfig: make syncconfig update .config regardless of sym_change_count
    kconfig: create directories needed for syncconfig by itself
    kconfig: remove unneeded directory generation from local*config
    kconfig: split out useful helpers in confdata.c
    kconfig: rename file_write_dep and move it to confdata.c
    kconfig: fix typos in description of "choice" in kconfig-language.txt
    kconfig: handle format string before calling conf_message_callback()
    kconfig: rename SYMBOL_AUTO to SYMBOL_NO_WRITE
    kconfig: check for pkg-config on make {menu,n,g,x}config

    Linus Torvalds
     

14 Aug, 2018

2 commits


13 Aug, 2018

1 commit

  • The rule of mainmenu_stmt does not have debug print of zconf_lineno(),
    but if it had, it would print a wrong line number for the same reason
    as commit b2d00d7c61c8 ("kconfig: fix line numbers for if-entries in
    menu tree").

    The mainmenu_stmt does not need to eat following empty lines because
    they are reduced to common_stmt.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

25 Jul, 2018

7 commits

  • Currently, only syncconfig creates or updates include/config/auto.conf
    and some other files. Other config targets create or update only the
    .config file.

    When you configure and build the kernel from a pristine source tree,
    any config target is followed by syncconfig in the build stage since
    include/config/auto.conf is missing.

    We are moving compiler tests from Makefile to Kconfig. It means that
    parsing Kconfig files will be more costly since Kconfig invokes the
    compiler commands internally. Thus, we want to avoid invoking Kconfig
    twice (one for *config to create the .config, and one for syncconfig
    to synchronize the auto.conf). If auto.conf does not exist, we can
    generate all configuration files in the first configuration stage,
    which will save the syncconfig in the build stage.

    Please note this should be done only when auto.conf is missing. If
    *config blindly did this, time stamp files under include/config/ would
    be unnecessarily touched, triggering unneeded rebuild of objects.

    I assume a scenario like this:

    1. You have a source tree that has already been built
    with CONFIG_FOO disabled

    2. Run "make menuconfig" to enable CONFIG_FOO

    3. CONFIG_FOO turns out to be unnecessary.
    Run "make menuconfig" again to disable CONFIG_FOO

    4. Run "make"

    In this case, include/config/foo.h should not be touched since there
    is no change in CONFIG_FOO. The sync process should be delayed until
    the user really attempts to build the kernel.

    This commit has another motivation; I want to suppress the 'No such
    file or directory' warning from the 'include' directive.

    The top-level Makefile includes auto.conf with '-include' directive,
    like this:

    ifeq ($(dot-config),1)
    -include include/config/auto.conf
    endif

    This looks strange because auto.conf is mandatory when dot-config is 1.
    I guess only the reason of using '-include' is to suppress the warning
    'include/config/auto.conf: No such file or directory' when building
    from a clean tree. However, this has a side-effect; Make considers
    the files included by '-include' are optional. Hence, Make continues
    to build even if it fails to generate include/config/auto.conf. I will
    change this in the next commit, but the warning message is annoying.
    (At least, kbuild test robot reports it as a regression.)

    With this commit, Kconfig will generate all configuration files together
    with the .config and I guess it is a solution good enough to suppress
    the warning.

    Note:
    GNU Make 4.2 or later does not display the warning from the 'include'
    directive if include files are successfully generated. See GNU Make
    commit 87a5f98d248f ("[SV 102] Don't show unnecessary include file
    errors.") However, older GNU Make versions are still widely used.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • syncconfig updates the .config only when sym_change_count > 0, i.e.
    any change in config symbols has been detected.

    Not only symbols but also comments are contained in the .config file.
    If only comments are updated, they are not fed back to the .config,
    then the stale comments are left-over. Of course, this is just a
    matter of comments, but why not fix it.

    I see some scenarios where this happens.

    Scenario A:

    1. You have a source tree that has already been configured.

    2. Linus increments the version number in the top-level Makefile
    (i.e. he commits a new release)

    3. You pull it, and run 'make'

    4. syncconfig is invoked because the environment variable,
    KERNELVERSION is updated, but the .config is not updated since
    no config symbol is changed.

    5. The .config file contains a kernel version in the top line:

    # Automatically generated file; DO NOT EDIT.
    # Linux/arm64 4.18.0-rc2 Kernel Configuration

    ... which points to a previous version.

    Scenario B:

    1. You have a source tree that has already been configured.

    2. You upgrade the compiler, but it still has the same version number.
    This may happen if you regularly build the latest compiler from
    the source code.

    3. You run 'make'

    4. syncconfig is invoked because the environment variable,
    CC_VERSION_TEXT is updated, but the .config is not updated since
    no config symbol is changed.

    5. The .config file contains the version string of the compiler:

    #
    # Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)
    #

    ... which carries the information of the old compiler.

    If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update
    the .config file. Otherwise, it is fine to update it regardless of
    sym_change_count.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • 'make syncconfig' creates some files such as include/config/auto.conf,
    include/generate/autoconf.h, etc. but the necessary directory creation
    relies on scripts/kconfig/Makefile.

    To make Kconfig self-contained, create directories as needed in
    conf_write_autoconf().

    This change allows scripts/kconfig/Makefile cleanups; syncconfig can
    be merged into simple-targets.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Commit 17263baf958b ("kconfig: Create include/generated for
    localmodconfig") added the 'mkdir' line because local{yes,mod}config
    ran streamline_config.pl followed by silentoldconfig at that time.

    Since commit 81d2bc227305 ("kconfig: invoke oldconfig instead of
    silentoldconfig from local*config"), no sub-directory is required.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Split out helpers:
    is_present() - check if the given path exists
    is_dir() - check if the given path exists and it is a directory
    make_parent_dir() - create the parent directories of the given path

    These helpers will be reused in later commits.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • file_write_dep() is called only from conf_write_autoconf().
    Move it from util.c to confdata.c to make it static.
    Also, rename it to conf_write_dep() since it should belong to
    the group of conf_write* functions.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • As you see in mconf.c and nconf.c, conf_message_callback() hooks are
    likely to end up with the boilerplate of vsnprintf(). Process the
    string format before calling conf_message_callback() so that it
    receives a simple string.

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

    Masahiro Yamada
     

18 Jul, 2018

3 commits

  • Over time, the use of the flag SYMBOL_AUTO changed from initially
    marking three automatically generated symbols ARCH, KERNELRELEASE and
    UNAME_RELEASE to today's effect of protecting symbols from being
    written out.

    Currently, only symbols of type CHOICE and those with option
    defconf_list set have that flag set.

    Reflect that change in semantics in the flag's name.

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

    Dirk Gouders
     
  • Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
    that other required files are present and to determine build flags
    settings, but none of these check that pkg-config itself is present.
    Add a check for all 4 of these targets and update
    Documentation/process/changes.rst to mention 'pkg-config'.

    Fixes kernel bugzilla #77511:
    https://bugzilla.kernel.org/show_bug.cgi?id=77511

    Signed-off-by: Randy Dunlap
    Cc: Bjørn Forsman
    Signed-off-by: Masahiro Yamada

    Randy Dunlap
     
  • In preparation for enabling command line LDLIBS, re-name HOST_LOADLIBES
    to KBUILD_HOSTLDLIBS as the internal use only flags. Also rename
    existing usage to HOSTLDLIBS for consistency. This should not have any
    visible effects.

    Signed-off-by: Laura Abbott
    Signed-off-by: Masahiro Yamada

    Laura Abbott
     

28 Jun, 2018

2 commits

  • If buf[-1] just happens to hold the byte 0x0A, then nread can wrap around
    to (size_t)-1, leading to invalid memory accesses.

    This has caused segmentation faults when trying to build the latest
    kernel snapshots for i686 in Fedora:
    https://bugzilla.redhat.com/show_bug.cgi?id=1592374

    Signed-off-by: Jerry James
    [alexpl@fedoraproject.org: reformatted patch for submission]
    Signed-off-by: Alexander Ploumistos
    Signed-off-by: Masahiro Yamada

    Jerry James
     
  • Each symbol has a property of type P_SYMBOL since commit
    59e89e3ddf85 (kconfig: save location of config symbols).
    Handle those properties in print_symbol().

    Further, place a pointer to print_symbol() in the comment above the
    list of known property type.

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

    Dirk Gouders
     

25 Jun, 2018

1 commit

  • The line numers for if-entries in the menu tree are off by one or more
    lines which is confusing when debugging for correctness of unrelated changes.

    According to the git log, commit a02f0570ae201c49 (kconfig: improve
    error handling in the parser) was the last one that changed that part
    of the parser and replaced

    "if_entry: T_IF expr T_EOL"
    by
    "if_entry: T_IF expr nl"

    but the commit message does not state why this has been done.

    When reverting that part of the commit, only the line numers are
    corrected (checked with cdebug = DEBUG_PARSE in zconf.y), otherwise
    the menu tree remains unchanged (checked with zconfdump() enabled in
    conf.c).

    An example for the corrected line numbers:

    drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig
    drivers/soc/tegra/Kconfig:4:if
    drivers/soc/tegra/Kconfig:6:if

    changes to:

    drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig
    drivers/soc/tegra/Kconfig:1:if
    drivers/soc/tegra/Kconfig:4:if

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

    Dirk Gouders
     

11 Jun, 2018

1 commit

  • When kconfig syntax moved to use $(FOO) for environment variables
    localmodconfig was not updated.
    Fix so it now works with the new syntax $(FOO)

    Fixes: 104daea149c4 ("kconfig: reference environment variables directly and remove 'option env='")
    Reported-by: Kevin Locke
    Reported-by: Andrei Vagin
    Signed-off-by: Sam Ravnborg
    Tested-by: Kevin Locke
    Signed-off-by: Masahiro Yamada

    Sam Ravnborg
     

05 Jun, 2018

3 commits

  • In file included from scripts/kconfig/zconf.tab.c:2485:
    scripts/kconfig/confdata.c: In function ‘conf_write’:
    scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
    sprintf(newname, "%s%s", dirname, basename);
    ^~
    scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
    sprintf(newname, "%s%s", dirname, basename);
    ^~~~~~
    scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
    sprintf(newname, "%s%s", dirname, basename);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
    sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
    ^~~~~~~~~~~
    scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
    sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Increase the size of tmpname and newname to make GCC happy.

    Cc: stable@vger.kernel.org
    Signed-off-by: Nathan Chancellor
    Signed-off-by: Masahiro Yamada

    Nathan Chancellor
     
  • Signed-off-by: Petr Vorel
    Signed-off-by: Masahiro Yamada

    Petr Vorel
     
  • Signed-off-by: Petr Vorel
    Signed-off-by: Masahiro Yamada

    Petr Vorel
     

29 May, 2018

9 commits

  • Here are the test cases I used for developing the text expansion
    feature.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • When using a recursively expanded variable, it is a common mistake
    to make circular reference.

    For example, Make terminates the following code:

    X = $(X)
    Y := $(X)

    Let's detect the circular expansion in Kconfig, too.

    On the other hand, a function that recurses itself is a commonly-used
    programming technique. So, Make does not check recursion in the
    reference with 'call'. For example, the following code continues
    running eternally:

    X = $(call X)
    Y := $(X)

    Kconfig allows circular expansion if one or more arguments are given,
    but terminates when the same function is recursively invoked 1000 times,
    assuming it is a programming mistake.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • The special variables, $(filename) and $(lineno), are expanded to a
    file name and its line number being parsed, respectively.

    Suggested-by: Randy Dunlap
    Signed-off-by: Masahiro Yamada
    Reviewed-by: Kees Cook

    Masahiro Yamada
     
  • Syntax:
    $(info,)
    $(warning-if,,)
    $(error-if,, part is y.

    Kconfig does not implement the lazy expansion as used in the 'if'
    'and, 'or' functions in Make. In other words, Kconfig does not
    support conditional expansion. The unconditional 'error' function
    would always terminate the parsing, hence would be useless in Kconfig.

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Kees Cook

    Masahiro Yamada
     
  • Make expands the lefthand side of assignment statements. In fact,
    Kbuild relies on it since kernel makefiles mostly look like this:

    obj-$(CONFIG_FOO) += foo.o

    Do likewise in Kconfig.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Support += operator. This appends a space and the text on the
    righthand side to a variable.

    The timing of the evaluation of the righthand side depends on the
    flavor of the variable. If the lefthand side was originally defined
    as a simple variable, the righthand side is expanded immediately.
    Otherwise, the expansion is deferred. Appending something to an
    undefined variable results in a recursive variable.

    To implement this, we need to remember the flavor of variables.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • The previous commit added variable and user-defined function. They
    work similarly in the sense that the evaluation is deferred until
    they are used.

    This commit adds another type of variable, simply expanded variable,
    as we see in Make.

    The := operator defines a simply expanded variable, expanding the
    righthand side immediately. This works like traditional programming
    language variables.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Now, we got a basic ability to test compiler capability in Kconfig.

    config CC_HAS_STACKPROTECTOR
    def_bool $(shell,($(CC) -Werror -fstack-protector -E -x c /dev/null -o /dev/null 2>/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 that. Hence, here is another
    feature, user-defined function. This works as a textual shorthand
    with parameterization.

    A user-defined function is defined by using the = operator, and can
    be referenced in the same way as built-in functions. A user-defined
    function in Make is referenced like $(call my-func,arg1,arg2), but I
    omitted the 'call' to make the syntax shorter.

    The definition of a user-defined function contains $(1), $(2), etc.
    in its body to reference the parameters. It is grammatically valid
    to pass more or fewer arguments when calling it. We already exploit
    this feature in our makefiles; scripts/Kbuild.include defines cc-option
    which takes two arguments at most, but most of the callers pass only
    one argument.

    By the way, a variable is supported as a subset of this feature since
    a variable is "a user-defined function with zero argument". In this
    context, I mean "variable" as recursively expanded variable. I will
    add a different flavored variable in the next commit.

    The code above can be written as follows:

    [Example Code]

    success = $(shell,($(1)) >/dev/null 2>&1 && echo y || echo n)
    cc-option = $(success,$(CC) -Werror $(1) -E -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

    Masahiro Yamada
     
  • Currently, any statement line starts with a keyword with TF_COMMAND
    flag. So, the following three lines are dead code.

    alloc_string(yytext, yyleng);
    zconflval.string = text;
    return T_WORD;

    If a T_WORD token is returned in this context, it will cause syntax
    error in the parser anyway.

    The next commit will support the assignment statement where a line
    starts with an arbitrary identifier. So, I want the lexer to switch
    to the PARAM state only when it sees a command keyword.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada