| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
This can be checked on-the-fly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Remove inputbox_order, searchbox, searchbox_title, searchbox_border
because they are initialized, but not used anywhere.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
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>
|
|
If the find_fromsym() call fails and returns NULL, the warn() call
will dereference this NULL pointer and cause the program to crash.
This happened when I tried to build with "test_user_copy" module.
With this fix, it prints lots of warnings like this:
WARNING: modpost: lib/test_user_copy: section mismatch in reference: (unknown)+0x4 (section: .text.fixup) -> (unknown) (section: .init.text)
masahiroy@kernel.org:
The issue is reproduced with ARCH=arm allnoconfig + CONFIG_MODULES=y +
CONFIG_RUNTIME_TESTING_MENU=y + CONFIG_TEST_USER_COPY=m
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Commit 4a5838ad9d2d ("kbuild: Add extra gcc checks") added the
-Wpacked-bitfield-compat flag, but there is no need to add it
explicitly.
GCC manual says:
"This warning is enabled by default. Use -Wno-packed-bitfield-compat
to disable this warning."
The test code in the manual:
struct foo
{
char a:4;
char b:8;
} __attribute__ ((packed));
... emits "note: offset of packed bit-field ‘b’ has changed in GCC 4.4"
without W=3.
Let's remove it, as it is a default with GCC.
Clang does not support this flag, so its removal will not affect Clang
builds.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
|
|
Commit 25b146c5b8ce ("kbuild: allow Kbuild to start from any directory")
exported abs_srctree and abs_objtree to avoid recomputation after the
sub-make. However, this approach turned out to be fragile.
Commit 5fa94ceb793e ("kbuild: set correct abs_srctree and abs_objtree
for package builds") moved them above "ifneq ($(sub_make_done),1)",
eliminating the need for exporting them.
These are only needed in the top Makefile. If an absolute path is
required in sub-directories, you can use $(abspath ) or $(realpath )
as needed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
|
|
Clang enables -Wenum-enum-conversion and -Wenum-compare-conditional
under -Wenum-conversion. A recent change in Clang strengthened these
warnings and they appear frequently in common builds, primarily due to
several instances in common headers but there are quite a few drivers
that have individual instances as well.
include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
| ~~~~~~~~~~~~~~~~~~~~~ ^
509 | item];
| ~~~~
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:955:24: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional]
955 | flags |= is_new_rate ? IWL_MAC_BEACON_CCK
| ^ ~~~~~~~~~~~~~~~~~~
956 | : IWL_MAC_BEACON_CCK_V1;
| ~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:1120:21: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional]
1120 | 0) > 10 ?
| ^
1121 | IWL_MAC_BEACON_FILS :
| ~~~~~~~~~~~~~~~~~~~
1122 | IWL_MAC_BEACON_FILS_V1;
| ~~~~~~~~~~~~~~~~~~~~~~
Doing arithmetic between or returning two different types of enums could
be a bug, so each of the instance of the warning needs to be evaluated.
Unfortunately, as mentioned above, there are many instances of this
warning in many different configurations, which can break the build when
CONFIG_WERROR is enabled.
To avoid introducing new instances of the warnings while cleaning up the
disruption for the majority of users, disable these warnings for the
default build while leaving them on for W=1 builds.
Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/2002
Link: https://github.com/llvm/llvm-project/commit/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37e
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
For the same rationale as commit 54b8ae66ae1a ("kbuild: change
*FLAGS_<basetarget>.o to take the path relative to $(obj)").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
|
|
Commit 54b8ae66ae1a ("kbuild: change *FLAGS_<basetarget>.o to take the
path relative to $(obj)") changed the syntax of per-file compiler flags.
The situation is the same for the following variables:
OBJECT_FILES_NON_STANDARD_<basetarget>.o
GCOV_PROFILE_<basetarget>.o
KASAN_SANITIZE_<basetarget>.o
KMSAN_SANITIZE_<basetarget>.o
KMSAN_ENABLE_CHECKS_<basetarget>.o
UBSAN_SANITIZE_<basetarget>.o
KCOV_INSTRUMENT_<basetarget>.o
KCSAN_SANITIZE_<basetarget>.o
KCSAN_INSTRUMENT_BARRIERS_<basetarget>.o
The <basetarget> is the filename of the target with its directory and
suffix stripped.
This syntax comes into a trouble when two files with the same basename
appear in one Makefile, for example:
obj-y += dir1/foo.o
obj-y += dir2/foo.o
OBJECT_FILES_NON_STANDARD_foo.o := y
OBJECT_FILES_NON_STANDARD_foo.o is applied to both dir1/foo.o and
dir2/foo.o. This syntax is not flexbile enough to handle cases where
one of them is a standard object, but the other is not.
It is more sensible to use the relative path to the Makefile, like this:
obj-y += dir1/foo.o
OBJECT_FILES_NON_STANDARD_dir1/foo.o := y
obj-y += dir2/foo.o
OBJECT_FILES_NON_STANDARD_dir2/foo.o := y
To maintain the current behavior, I made adjustments to the following two
Makefiles:
- arch/x86/entry/vdso/Makefile, which compiles vclock_gettime.o, vgetcpu.o,
and their vdso32 variants.
- arch/x86/kvm/Makefile, which compiles vmx/vmenter.o and svm/vmenter.o
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Acked-by: Sean Christopherson <seanjc@google.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
This is similar to include/linux/hashtable.h, but the implementation
has been simplified.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Import more macros and inline functions from include/linux/list.h
and include/linux/types.h.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
Call malloc() just once to allocate needed memory.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
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>
|
|
Replace the remaining current_file->name in the lexer context.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
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>
|
|
The 'file->name' and 'name' are the same in this function.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
sym_find("n") is equivalent to &symbol_no.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
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>
|
|
There is no definition, no caller for lookup_file().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
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>
|
|
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>
|
|
This reverts commit 6ef41e22a320d95a246d45b673aa7247cc1bbf7b.
If this is still needed, we can bring it back.
However, I'd like to understand why 'new-kernel-pkg --remove' is
needed for uninstallation, while 'new-kernel-pkg --install' was not
called during the installation.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
This reverts commit 27c3bffd230abd0a598586aed0fe0ba7b61e0e2e.
If this is still needed, we can bring it back.
However, I'd like to understand why 'update-bootloader --remove' is
needed for uninstallation, while 'update-bootloader --add' was not
called during the installation.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Mark the files installed to /boot as %ghost to make sure they will be
removed when the package is uninstalled.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
|
|
Installing the kernel package is fine, but when uninstalling it, the
following warnings are shown:
warning: file modules.symbols.bin: remove failed: No such file or directory
warning: file modules.symbols: remove failed: No such file or directory
warning: file modules.softdep: remove failed: No such file or directory
warning: file modules.devname: remove failed: No such file or directory
warning: file modules.dep.bin: remove failed: No such file or directory
warning: file modules.dep: remove failed: No such file or directory
warning: file modules.builtin.bin: remove failed: No such file or directory
warning: file modules.builtin.alias.bin: remove failed: No such file or directory
warning: file modules.alias.bin: remove failed: No such file or directory
warning: file modules.alias: remove failed: No such file or directory
The %preun scriptlet runs 'kernel-install remove', which in turn invokes
/usr/lib/kernel/install.d/50-depmod.install to remove those files before
the actual package removal.
RPM-based distributions do not ship files generated by depmod. Mark them
as %ghost in order to exclude them from the package, but still claim the
ownership on them.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
|
|
Use dh_prep instead of removing old build directories manually.
Use dh_clean instead of removing build directories and debian/files
manually.
Call dh_testdir and dh_testroot for preliminary checks.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
|
|
'make deb-pkg' builds build-arch in parallel, but binary-arch serially.
Given that all binary packages are independent of one another, they can
be built in parallel.
I am uncertain whether debian/files is robust against a race condition.
Just in case, make dh_gencontrol (dpkg-gencontrol) output to separate
debian/*.files, which are then concatenated into debian/files.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
|
|
Add $(Q) to the commands in debian/rules to make them quiet when the
package built is initiated by 'make deb-pkg' or when the 'terse' tag
is set to DEB_BUILD_OPTIONS.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
|
|
When the Debian package build is initiated by Kbuild ('make deb-pkg'
or 'make bindeb-pkg'), the log messages are displayed in the short
form, which is the Kbuild default.
Otherwise, let's show verbose messages (unless the 'terse' tag is set
in DEB_BUILD_OPTION), as suggested by Debian Policy: "The package build
should be as verbose as reasonably possible, except where the terse tag
is included in DEB_BUILD_OPTIONS." [1]
This is what the Debian kernel also does. [2]
[1]: https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules
[2]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.7-1_exp1/debian/rules.real#L36
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
|
