summaryrefslogtreecommitdiffstats
path: root/scripts/kconfig
Commit message (Collapse)AuthorAgeFilesLines
* kconfig: Fix typo HEIGTH to HEIGHTIsak Ellmer2024-03-318-14/+14
| | | | | | | Fixed a typo in some variables where height was misspelled as heigth. Signed-off-by: Isak Ellmer <isak01@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: do not reparent the menu inside a choice blockMasahiro Yamada2024-03-284-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The boolean 'choice' is used to list exclusively selected config options. You must not add a dependency between choice members, because such a dependency would create an invisible entry. In the following test case, it is impossible to choose 'C'. [Test Case 1] choice prompt "Choose one, but how to choose C?" config A bool "A" config B bool "B" config C bool "C" depends on A endchoice Hence, Kconfig shows the following error message: Kconfig:1:error: recursive dependency detected! Kconfig:1: choice <choice> contains symbol C Kconfig:10: symbol C is part of choice A Kconfig:4: symbol A is part of choice <choice> For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" However, Kconfig does not report anything for the following similar code: [Test Case 2] choice prompt "Choose one, but how to choose B?" config A bool "A" config B bool "B" depends on A config C bool "C" endchoice This is because menu_finalize() reparents the menu tree when an entry depends on the preceding one. With reparenting, the menu tree: choice |- A |- B \- C ... will be transformed into the following structure: choice |- A | \- B \- C Consequently, Kconfig considers only 'A' and 'C' as choice members. This behavior is awkward. The second test case should be an error too. This commit stops reparenting inside a choice. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: tests: test dependency after shuffling choicesMasahiro Yamada2024-03-215-0/+71
| | | | | | | | | | | | | | | | | | | | | Commit c8fb7d7e48d1 ("kconfig: fix broken dependency in randconfig- generated .config") fixed the issue, but I did not add a test case. This commit adds a test case that emulates the reported situation. The test would fail without c8fb7d7e48d1. To handle the choice "choose X", FOO must be calculated beforehand. FOO depends on A, which is a member of another choice "choose A or B". Kconfig _temporarily_ assumes the value of A to proceed. The choice "choose A or B" will be shuffled later, but the result may or may not meet "FOO depends on A". Kconfig should invalidate the symbol values and recompute them. In the real example for ARCH=arm64, the choice "Instrumentation type" needs the value of CPU_BIG_ENDIAN. The choice "Endianness" will be shuffled later. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: tests: add a test for randconfig with dependent choicesMasahiro Yamada2024-03-215-0/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig"), conf_set_all_new_symbols() is repeated until there is no more choice left to be shuffled. The motivation was to shuffle a choice nested in another choice. Although commit 09d5873e4d1f ("kconfig: allow only 'config', 'comment', and 'if' inside 'choice'") disallowed the nested choice structure, we must still keep 3b9a19e08960 because there are still cases where conf_set_all_new_symbols() must iterate. scripts/kconfig/tests/choice_randomize/Kconfig is the test case. The second choice depends on 'B', which is the member of the first choice. With 3b9a19e08960 reverted, we would never get the pattern specified by scripts/kconfig/tests/choice_randomize/expected_config2. A real example can be found in lib/Kconfig.debug. Without 3b9a19e08960, the randconfig would not shuffle the "Compressed Debug information" choice, which depends on DEBUG_INFO, which is derived from another choice "Debug information". My goal is to refactor Kconfig so that randconfig will work more simply, without using the loop. For now, let's add a test case to ensure all dependent choices are shuffled, as it is a somewhat tricky case for the current Kconfig. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: tests: support KCONFIG_SEED for the randconfig runnerMasahiro Yamada2024-03-211-6/+10
| | | | | | This will help get consistent results for randconfig tests. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove unneeded menu_is_visible() call in conf_write_defconfig()Masahiro Yamada2024-03-191-4/+1
| | | | | | | | | | | When the condition 'sym == NULL' is met, the code will reach the 'next_menu' label regardless of the return value from menu_is_visible(). menu_is_visible() calculates some symbol values as a side-effect, for instance by calling expr_calc_value(menu->visibility), but all the symbol values will be calculated eventually. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: check prompt for choice while parsingMasahiro Yamada2024-03-192-3/+6
| | | | | | This can be checked on-the-fly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: lxdialog: remove unused dialog colorsMasahiro Yamada2024-03-192-22/+0
| | | | | | | Remove inputbox_order, searchbox, searchbox_title, searchbox_border because they are initialized, but not used anywhere. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: lxdialog: fix button color for blackbg themeMasahiro Yamada2024-03-191-1/+1
| | | | | | | | | For MENUCONFIG_COLOR=blackbg, the text in inactive buttons is invisible because both the foreground and background are black. Change the foreground color to white and remove the highlighting. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove named choice supportMasahiro Yamada2024-03-101-7/+3
| | | | | | | | | | | | Commit 5a1aa8a1aff6 ("kconfig: add named choice group") did not provide enough explanation regarding its benefits. A use case was found in another project [1] sometime later, this feature has never been used in the kernel. [1]: https://lore.kernel.org/all/201012150034.01356.yann.morin.1998@anciens.enib.fr/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
* kconfig: use linked list in get_symbol_str() to iterate over menusMasahiro Yamada2024-03-091-8/+9
| | | | | | | | | | | Currently, get_symbol_str() uses a tricky approach to traverse the associated menus. With relevant menus now linked to the symbol using a linked list, use list_for_each_entry() for iterating on the menus. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
* kconfig: link menus to a symbolMasahiro Yamada2024-03-093-1/+12
| | | | | | | | | | | | | Currently, there is no direct link from (struct symbol) to (struct menu). It is still possible to access associated menus through the P_SYMBOL property, because property::menu is the relevant menu entry, but it results in complex code, as seen in get_symbol_str(). Use a linked list for simpler traversal of relevant menus. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
* kconfig: lxdialog: fix cursor render in checklistMatthew Bystrin2024-02-201-3/+2
| | | | | | | | | | | | | | When a checklist is opened, the cursor is rendered in a wrong position (after the last list element on the screen). You can observe it by opening any checklist in menuconfig. Added wmove() to set the cursor in the proper position, just like in menubox.c. Removed wnoutrefresh(dialog) because dialog window has already been updated in print_buttons(). Replaced wnoutrefresh(list) and doupdate() calls with one wrefresh(list) call. Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: use generic macros to implement symbol hashtableMasahiro Yamada2024-02-207-39/+42
| | | | | | | | Use helper macros in hashtable.h for generic hashtable implementation. We can git rid of the hash head index of for_all_symbols(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: print recursive dependency errors in the parsed orderMasahiro Yamada2024-02-202-15/+27
| | | | | | | | | | | | | | for_all_symbols() iterates in the symbol hash table. The order of iteration depends on the hash table implementation. If you use it for printing errors, they are shown in random order. For example, the order of following test input and the corresponding error do not match: - scripts/kconfig/tests/err_recursive_dep/Kconfig - scripts/kconfig/tests/err_recursive_dep/expected_stderr Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: do not imply the type of choice valueMasahiro Yamada2024-02-201-6/+0
| | | | | | | | | | Do not feed back the choice type to choice values. Each choice value should explicitly specify 'bool' or 'tristate', as all the Kconfig files already do. If the type were missing, "config symbol defined without type" would be shown. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: convert linked list of files to hash tableMasahiro Yamada2024-02-201-9/+11
| | | | | | | | | | | | | | | | | | | Currently, a linked list is used to keep track of all the Kconfig files that have ever been parsed. Every time the "source" statement is encountered, the linked list is traversed to check if the file has been opened before. This prevents the same file from being recorded in include/config/auto.conf.cmd again. Given 1500+ Kconfig files parsed, a hashtable is now a more optimal data structure. By the way, you may wonder why we check this in the first place. It matters only when the same file is included multiple times. In old days, such a use case was forbidden, but commit f094f8a1b273 ("kconfig: allow multiple inclusion of the same file") provided a bit more flexibility. Of course, it is almost hypothetical... Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: move strhash() to util.c as a global functionMasahiro Yamada2024-02-203-9/+11
| | | | | | | Remove the 'static' qualifier from strhash() so that it can be accessed from other files. Move it to util.c, which is a more appropriate location. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: move ARRAY_SIZE to a headerMasahiro Yamada2024-02-192-2/+12
| | | | | | | To use ARRAY_SIZE from other files, move it to its own header, just like include/linux/array_size.h. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: add macros useful for hashtableMasahiro Yamada2024-02-191-0/+48
| | | | | | | This is similar to include/linux/hashtable.h, but the implementation has been simplified. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: import more list macros and inline functionsMasahiro Yamada2024-02-192-0/+77
| | | | | | | Import more macros and inline functions from include/linux/list.h and include/linux/types.h. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: resync list.hMasahiro Yamada2024-02-191-62/+121
| | | | | | | | | | Update the existing macros and inline functions based on include/linux/list.h. The variable name '_new' can be reverted to 'new' because this header is no longer included from the C++ file, scripts/kconfig/qconf.cc. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: split list_head into a separate headerMasahiro Yamada2024-02-196-7/+15
| | | | | | | | | | | | | The struct list_head is often embedded in other structures, while other code is used in C functions. By separating struct list_head into its own header, other headers are no longer required to include the entire list.h. This is similar to the kernel space, where struct list_head is defined in <linux/types.h> instead of <linux/list.h>. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: change file_lookup() to return the file nameMasahiro Yamada2024-02-195-16/+13
| | | | | | | | | | | | Currently, file_lookup() returns a pointer to (struct file), but the callers use only file->name. Make it return the ->name member directly. This adjustment encapsulates struct file and file_list as internal implementation. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: make file::name a flexible array memberMasahiro Yamada2024-02-192-3/+6
| | | | | | Call malloc() just once to allocate needed memory. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: move the file and lineno in struct file to struct bufferMasahiro Yamada2024-02-193-33/+23
| | | | | | | | | | | | | | struct file has two link nodes, 'next' and 'parent'. The former is used to link files in the 'file_list' linked list, which manages the list of Kconfig files seen so far. The latter is used to link files in the 'current_file' linked list, which manages the inclusion ("source") tree. The latter should be tracked together with the lexer state. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: replace remaining current_file->name with cur_filenameMasahiro Yamada2024-02-192-6/+6
| | | | | | Replace the remaining current_file->name in the lexer context. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: do not delay the cur_filename updateMasahiro Yamada2024-02-192-10/+15
| | | | | | | | Currently, cur_filename is updated at the first token of each statement. However, this seems unnecessary based on my understanding; the parser can use the same variable as the lexer tracks. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: replace file->name with name in zconf_nextfile()Masahiro Yamada2024-02-191-5/+5
| | | | | | The 'file->name' and 'name' are the same in this function. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: associate struct property with file name directlyMasahiro Yamada2024-02-193-9/+9
| | | | | | | | | struct property is linked to struct file for diagnostic purposes. It is always used to retrieve the file name through prop->file->name. Associate struct property with the file name directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: associate struct menu with file name directlyMasahiro Yamada2024-02-195-10/+10
| | | | | | | | | struct menu is linked to struct file for diagnostic purposes. It is always used to retrieve the file name through menu->file->name. Associate struct menu with the file name directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove zconf_curname() and zconf_lineno()Masahiro Yamada2024-02-195-51/+37
| | | | | | | | | | Now zconf_curname() and zconf_lineno() are so simple that they just return cur_filename, cur_lineno, respectively. Remove these functions, and then use cur_filename and cur_lineno directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: replace current_pos with separate cur_{filename,lineno}Masahiro Yamada2024-02-191-8/+17
| | | | | | | | | | | | | | | | Replace current_pos with separate variables representing the file name and the line number, respectively. No functional change is intended. By the way, you might wonder why the "<none>" fallback exists in zconf_curname(). menu_add_symbol() saves the current file and the line number. It is intended to be called only during the yyparse() time. However, menu_finalize() calls it, where there is no file being parsed. This is a long-standing hack that should be fixed later. I left a FIXME comment. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: split preprocessor prototypes into preprocess.hMasahiro Yamada2024-02-195-13/+23
| | | | | | | These are needed only for the parse stage. Move the prototypes into a separate header to make sure they are not used after that. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: call env_write_dep() right after yyparse()Masahiro Yamada2024-02-194-12/+18
| | | | | | | | This allows preprocess.c to free up all of its resources when the parse stage is finished. It also ensures conf_write_autoconf_cmd() produces consistent results even if called multiple times for any reason. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: write Kconfig files to autoconf.cmd in orderMasahiro Yamada2024-02-194-4/+11
| | | | | | | | | | Currently, include/config/autoconf.cmd saves included Kconfig files in reverse order. While this is not a big deal, it is inconsistent with other *.cmd files generated by fixdep. Output the included Kconfig files in the included order. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove unneeded sym_find() call in conf_parse()Masahiro Yamada2024-02-191-1/+1
| | | | | | sym_find("n") is equivalent to &symbol_no. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove compat_getline()Masahiro Yamada2024-02-191-52/+1
| | | | | | | | | | | | | | Commit 1a7a8c6fd8ca ("kconfig: allow long lines in config file") added a self-implemented getline() for better portability. However, getline() is standardized [1] and already used in other programs such as scripts/kallsyms.c. Use getline() provided by libc. [1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/getdelim.html Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove orphan lookup_file() declarationMasahiro Yamada2024-02-191-1/+0
| | | | | | There is no definition, no caller for lookup_file(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: fix off-by-one in zconf_error()Masahiro Yamada2024-02-191-1/+1
| | | | | | | | | | | | | | yyerror() reports the line number of the next line. This +1 adjustment was introduced more than 20 years ago [1]. At that time, the line number was decremented then incremented back and forth. The line number management was refactored in a more maintainable way. Such compensation is no longer needed. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=d4f8a4530eb07a1385fd17b0e62a7dce97486f49 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: fix infinite loop when expanding a macro at the end of fileMasahiro Yamada2024-02-191-2/+5
| | | | | | | | | | | | | | | A macro placed at the end of a file with no newline causes an infinite loop. [Test Kconfig] $(info,hello) \ No newline at end of file I realized that flex-provided input() returns 0 instead of EOF when it reaches the end of a file. Fixes: 104daea149c4 ("kconfig: reference environment variables directly and remove 'option env='") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: fix line number in recursive inclusion detectionMasahiro Yamada2024-02-191-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The error message shows a wrong line number if the 'source' directive is wrapped to the following line. [Test Code] source \ "Kconfig" This results in the following error message: Recursive inclusion detected. Inclusion path: current file : Kconfig included from: Kconfig:2 The correct message should be as follows: Recursive inclusion detected. Inclusion path: current file : Kconfig included from: Kconfig:1 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove unneeded buffer allocation in zconf_initscan()Masahiro Yamada2024-02-191-16/+13
| | | | | | | | | | | In Kconfig, there is a stack to save the lexer state for each inclusion level. Currently, it operates as an empty stack, with the 'current_buf' always pointing to an empty buffer. There is no need to preallocate the buffer. Change it to a full stack. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: initialize sym->curr.tri to 'no' for all symbol types againMasahiro Yamada2024-01-311-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Geert Uytterhoeven reported that commit 4e244c10eab3 ("kconfig: remove unneeded symbol_empty variable") changed the default value of CONFIG_LOG_CPU_MAX_BUF_SHIFT from 12 to 0. As it turned out, this is an undefined behavior because sym_calc_value() stopped setting the sym->curr.tri field for 'int', 'hex', and 'string' symbols. This commit restores the original behavior, where 'int', 'hex', 'string' symbols are interpreted as false if used in boolean contexts. CONFIG_LOG_CPU_MAX_BUF_SHIFT will default to 12 again, irrespective of CONFIG_BASE_SMALL. Presumably, this is not the intended behavior, as already reported [1], but this is another issue that should be addressed by a separate patch. [1]: https://lore.kernel.org/all/f6856be8-54b7-0fa0-1d17-39632bf29ada@oracle.com/ Fixes: 4e244c10eab3 ("kconfig: remove unneeded symbol_empty variable") Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Closes: https://lore.kernel.org/all/CAMuHMdWm6u1wX7efZQf=2XUAHascps76YQac6rdnQGhc8nop_Q@mail.gmail.com/ Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: WERROR unmet symbol dependencySergey Senozhatsky2023-12-294-5/+25
| | | | | | | | | When KCONFIG_WERROR env variable is set treat unmet direct symbol dependency as a terminal condition (error). Suggested-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: Use KCONFIG_CONFIG instead of .configMarkus Schneider-Pargmann2023-12-281-1/+1
| | | | | | | | | When using a custom location for kernel config files this merge config command fails as it doesn't use the configuration set with KCONFIG_CONFIG. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove redundant NULL pointer check before free()Masahiro Yamada2023-12-282-4/+2
| | | | | | | | Passing NULL to free() is allowed and is a no-op. Remove redundant NULL pointer checks. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove unreachable printf()Masahiro Yamada2023-12-281-1/+0
| | | | | | | | | | | | | Remove the unreachable code detected by clang. $ make HOSTCC=clang HOSTCFLAGS=-Wunreachable-code defconfig [ snip ] scripts/kconfig/expr.c:1134:2: warning: code will never be executed [-Wunreachable-code] printf("[%dgt%d?]", t1, t2); ^~~~~~ 1 warning generated. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: add include guard to lkc_proto.hMasahiro Yamada2023-12-281-0/+5
| | | | Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: squash menu_has_help() and menu_get_help()Masahiro Yamada2023-12-282-17/+2
| | | | | | | | | | | menu_has_help() and menu_get_help() functions are only used within menu_get_ext_help(). Squash them into menu_get_ext_help(). It revealed the if-conditional in menu_get_help() was unneeded, as menu_has_help() has already checked that menu->help is not NULL. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-20 08:29:52 +0000