IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Alexei Starovoitov says:
====================
pull-request: bpf-next 2021-04-23
The following pull-request contains BPF updates for your *net-next* tree.
We've added 69 non-merge commits during the last 22 day(s) which contain
a total of 69 files changed, 3141 insertions(+), 866 deletions(-).
The main changes are:
1) Add BPF static linker support for extern resolution of global, from Andrii.
2) Refine retval for bpf_get_task_stack helper, from Dave.
3) Add a bpf_snprintf helper, from Florent.
4) A bunch of miscellaneous improvements from many developers.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add '/' prefix to clarify that the generated files exist right under
scripts/kconfig/, but not in any sub-directory.
Replace '*conf-cfg' with '[gmnq]conf-cfg' to make it explicit, and
still short enough.
Use '[gmnq]conf' to combine gconf, mconf, nconf, and qconf.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Change the source package name from 'linux-$(KERNELRELEASE)' to
'linux-upstream'.
Initially, I tried to use 'linux' to be aligned with the Debian
kernel package, but Ben suggested 'linux-upstream' so that it is
clearly distinguished from distribution packages. [1]
The filenames will be changed as follows:
[Before]
linux-5.12.0-rc3+_5.12.0-rc3+-1.dsc
linux-5.12.0-rc3+_5.12.0-rc3+.orig.tar.gz
linux-5.12.0-rc3+_5.12.0-rc3+-1.diff.gz
[After]
linux-upstream_5.12.0-rc3+-1.dsc
linux-upstream_5.12.0-rc3+.orig.tar.gz
linux-upstream_5.12.0-rc3+-1.diff.gz
Commit 3716001bcb7f ("deb-pkg: add source package") introduced
KDEB_SOURCENAME. If you are unhappy with the default name, you can
override it via KDEB_SOURCENAME.
[1]: https://lore.kernel.org/linux-kbuild/06ffa2a690d57f867b4bc1b42f0026917b1dd3cd.camel@decadent.org.uk/T/#m2c4afa0eca5ced5e57795b002f2dbcb05d7a4a44
Suggested-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
TMPO is only used by arch/x86/Makefile.
Change arch/x86/Makefile to use $$TMPO.o and remove TMPO from
scripts/Makefile.compiler.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, clang LTO built vmlinux won't work with pahole.
LTO introduced cross-cu dwarf tag references and broke
current pahole model which handles one cu as a time.
The solution is to merge all cu's as one pahole cu as in [1].
We would like to do this merging only if cross-cu dwarf
references happens. The LTO build mode is a pretty good
indication for that.
In earlier version of this patch ([2]), clang flag
-grecord-gcc-switches is proposed to add to compilation flags
so pahole could detect "-flto" and then merging cu's.
This will increate the binary size of 1% without LTO though.
Arnaldo suggested to use a note to indicate the vmlinux
is built with LTO. Such a cheap way to get whether the vmlinux
is built with LTO or not helps pahole but is also useful
for tracing as LTO may inline/delete/demote global functions,
promote static functions, etc.
So this patch added an elfnote with a new type LINUX_ELFNOTE_LTO_INFO.
The owner of the note is "Linux".
With gcc 8.4.1 and clang trunk, without LTO, I got
$ readelf -n vmlinux
Displaying notes found in: .notes
Owner Data size Description
...
Linux 0x00000004 func
description data: 00 00 00 00
...
With "readelf -x ".notes" vmlinux", I can verify the above "func"
with type code 0x101.
With clang thin-LTO, I got the same as above except the following:
description data: 01 00 00 00
which indicates the vmlinux is built with LTO.
[1] https://lore.kernel.org/bpf/20210325065316.3121287-1-yhs@fb.com/
[2] https://lore.kernel.org/bpf/20210331001623.2778934-1-yhs@fb.com/
Suggested-by: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-rc4 (x86-64)
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
kmod 28 supports modules compressed in zstd format so let's add this
possibility to kernel.
Signed-off-by: Piotr Gorski <lucjan.lucjanov@gmail.com>
Reviewed-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
scripts/Makefile.modsign is a subset of scripts/Makefile.modinst,
and duplicates the code. Let's merge them.
By the way, you do not need to run 'make modules_sign' explicitly
because modules are signed as a part of 'make modules_install' when
CONFIG_MODULE_SIG_ALL=y. If CONFIG_MODULE_SIG_ALL=n, mod_sign_cmd is
set to 'true', so 'make modules_sign' is not functional.
In my understanding, the reason of still keeping this is to handle
corner cases like commit 64178cb62c32 ("builddeb: fix stripped module
signatures if CONFIG_DEBUG_INFO and CONFIG_MODULE_SIG_ALL are set").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Both mod_strip_cmd and mod_compress_cmd are only used in
scripts/Makefile.modinst, hence there is no good reason to define them
in the top Makefile. Move the relevant code to scripts/Makefile.modinst.
Also, show separate log messages for each of install, strip, sign, and
compress.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
scripts/Makefile.modinst is ugly and weird in multiple ways; it
specifies real files $(modules) as phony, makes directory manipulation
needlessly too complicated.
Clean up the Makefile code, and show the full path of installed modules
in the log.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
If there are multiple modules with the same name in the same external
module tree, there is ambiguity about which one will be loaded, and
very likely something odd is happening.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Nathan reports that the mips defconfig emits the following warning:
WARNING: modpost: Symbol info of vmlinux is missing. Unresolved symbol check will be entirely skipped.
This false-positive happens when CONFIG_TRIM_UNUSED_KSYMS is enabled,
but no CONFIG option is set to 'm'.
Commit a0590473c5e6 ("nfs: fix PNFS_FLEXFILE_LAYOUT Kconfig default")
turned the last 'm' into 'y' for the mips defconfig, and uncovered
this issue.
In this case, the module feature itself is enabled, but we have no
module to build. As a result, CONFIG_TRIM_UNUSED_KSYMS drops all the
instances of EXPORT_SYMBOL. Then, modpost wrongly assumes vmlinux is
missing because vmlinux.symvers is empty. (As another false-positive
case, you can create a module that does not use any symbol of vmlinux).
The current behavior is to entirely suppress the unresolved symbol
warnings when vmlinux is missing just because there are too many.
I found the origin of this code in the historical git tree. [1]
If this is a matter of noisiness, I think modpost can display the
first 10 warnings, and the number of suppressed warnings at the end.
You will get a bit noisier logs when you run 'make modules' without
vmlinux, but such warnings are better to show because you never know
the resulting modules are actually loadable or not.
This commit changes the following:
- If any of input *.symver files is missing, pass -w option to let
the module build keep going with warnings instead of errors.
- If there are too many (10+) unresolved symbol warnings, show only
the first 10, and also the number of suppressed warnings.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=1cc0e0529569bf6a94f6d49770aa6d4b599d2c46
Reported-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The -w option is meaningless for the first pass of modpost (vmlinux.o).
We know there are unresolved symbols in vmlinux.o, hence we skip
check_exports() and other checks when mod->is_vmlinux is set.
See the following part in the for-loop.
if (mod->is_vmlinux || mod->from_dump)
continue;
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The external module build shows the following warning if Module.symvers
is missing in the kernel tree.
WARNING: Symbol version dump "Module.symvers" is missing.
Modules may not have dependencies or modversions.
I think this is an important heads-up because the resulting modules may
not work as expected. This happens when you did not build the entire
kernel tree, for example, you might have prepared the minimal setups
for external modules by 'make defconfig && make modules_preapre'.
A problem is that 'make modules' creates Module.symvers even without
vmlinux. In this case, that warning is suppressed since Module.symvers
already exists in spite of its incomplete content.
The incomplete (i.e. invalid) Module.symvers should not be created.
This commit changes the second pass of modpost to dump symbols into
modules-only.symvers. The final Module.symvers is created by
concatenating vmlinux.symvers and modules-only.symvers if both exist.
Module.symvers is supposed to collect symbols from both vmlinux and
modules. It might be a bit confusing, and I am not quite sure if it
is an official interface, but presumably it is difficult to rename it
because some tools (e.g. kmod) parse it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The test code in scripts/test_dwarf5_support.sh is somewhat difficult
to understand, but after all, we want to check binutils >= 2.35.2
From the former discussion, the requirement for generating DWARF v5 from
C code is as follows:
- gcc + gnu as -> requires gcc 5.0+ (but 7.0+ for full support)
- clang + gnu as -> requires binutils 2.35.2+
- clang + integrated as -> OK
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Documentation/process/changes.rst defines the minimum assembler version
(binutils version), but we have never checked it in the build time.
Kbuild never invokes 'as' directly because all assembly files in the
kernel tree are *.S, hence must be preprocessed. I do not expect
raw assembly source files (*.s) would be added to the kernel tree.
Therefore, we always use $(CC) as the assembler driver, and commit
aa824e0c962b ("kbuild: remove AS variable") removed 'AS'. However,
we are still interested in the version of the assembler acting behind.
As usual, the --version option prints the version string.
$ as --version | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
But, we do not have $(AS). So, we can add the -Wa prefix so that
$(CC) passes --version down to the backing assembler.
$ gcc -Wa,--version | head -n 1
gcc: fatal error: no input files
compilation terminated.
OK, we need to input something to satisfy gcc.
$ gcc -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
The combination of Clang and GNU assembler works in the same way:
$ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
Clang with the integrated assembler fails like this:
$ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
clang: error: unsupported argument '--version' to option 'Wa,'
For the last case, checking the error message is fragile. If the
proposal for -Wa,--version support [1] is accepted, this may not be
even an error in the future.
One easy way is to check if -integrated-as is present in the passed
arguments. We did not pass -integrated-as to CLANG_FLAGS before, but
we can make it explicit.
Nathan pointed out -integrated-as is the default for all of the
architectures/targets that the kernel cares about, but it goes
along with "explicit is better than implicit" policy. [2]
With all this in my mind, I implemented scripts/as-version.sh to
check the assembler version in Kconfig time.
$ scripts/as-version.sh gcc
GNU 23501
$ scripts/as-version.sh clang -no-integrated-as
GNU 23501
$ scripts/as-version.sh clang -integrated-as
LLVM 0
[1]: https://github.com/ClangBuiltLinux/linux/issues/1320
[2]: https://lore.kernel.org/linux-kbuild/20210307044253.v3h47ucq6ng25iay@archlinux-ax161/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
The kernel build uses various tools, many of which are provided by the
same software suite, for example, LLVM and Binutils.
When you raise the minimum version of Clang/LLVM, you need to update
clang_min_version in scripts/cc-version.sh and also lld_min_version in
scripts/ld-version.sh.
Kbuild can handle CC=clang and LD=ld.lld independently, but it does not
make much sense to maintain their versions separately.
Let's create a central place of minimum tool versions so you do not need
to touch multiple files. scripts/min-tool-version.sh prints the minimum
version of the given tool.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Move $(strip ...) to the callee from the callers of suffix-search. It
shortens the code slightly. Adding a space after a comma will not be
a matter. I also dropped parentheses from single character variables.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
I think multi-obj-* is clearer, and more consistent with real-obj-*.
Rename as follows:
multi-used-y -> multi-obj-y
multi-used-m -> multi-obj-m
multi-used -> multi-obj-ym
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The patch adding CONFIG_VMLINUX_MAP revealed a small defect in the
build system: link-vmlinux.sh takes decisions based on CONFIG_*
options, but changing one of those does not always lead to vmlinux
being linked again.
For most of the CONFIG_* knobs referenced previously, this has
probably been hidden by those knobs also affecting some object file,
hence indirectly also vmlinux.
But CONFIG_VMLINUX_MAP is only handled inside link-vmlinux.sh, and
changing CONFIG_VMLINUX_MAP=n to CONFIG_VMLINUX_MAP=y does not cause
the build system to re-link (and hence have vmlinux.map
emitted). Since that map file is mostly a debugging aid, this is
merely a nuisance which is easily worked around by just deleting
vmlinux and building again.
But one could imagine other (possibly future) CONFIG options that
actually do affect the vmlinux binary but which are not captured
through some object file dependency.
To fix this, make link-vmlinux.sh emit a .vmlinux.d file in the same
format as the dependency files generated by gcc, and apply the fixdep
logic to that. I've tested that this correctly works with both in-tree
and out-of-tree builds.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
It can be quite useful to have ld emit a link map file, in order to
debug or verify that special sections end up where they are supposed
to, and to see what LD_DEAD_CODE_DATA_ELIMINATION manages to get rid
of.
The only reason I'm not just adding this unconditionally is that the
.map file can be rather large (several MB), and that's a waste of
space when one isn't interested in these things. Also make it depend
on CONFIG_EXPERT.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
scripts/Kbuild.include is included everywhere, but macros such as
cc-option are needed by build targets only.
For example, when 'make clean' traverses the tree, it does not need
to evaluate $(call cc-option,).
Split cc-option, ld-option, etc. to scripts/Makefile.compiler, which
is only included from the top Makefile and scripts/Makefile.build.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Mark Kconfig "comment" lines with "*** <commentstring> ***"
so that it is clear that these lines are comments and not some
kconfig item that cannot be modified.
This is helpful in some menus to be able to provide a menu
"sub-heading" for groups of similar config items.
This also makes the comments be presented in a way that is
similar to menuconfig and nconfig.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Mark Kconfig "comment" lines with "*** <commentstring> ***"
so that it is clear that these lines are comments and not some
kconfig item that cannot be modified.
This is helpful in some menus to be able to provide a menu
"sub-heading" for groups of similar config items.
This also makes the comments be presented in a way that is
similar to menuconfig and nconfig.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit 3b9fa0931dd8 ("[PATCH] Kconfig i18n support") added this code,
and then commit ("kconfig: drop localization support") removed the
i18n support entirely.
Remove the left-over.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
- keep the ZC code, drop the code related to reinit
net/bridge/netfilter/ebtables.c
- fix build after move to net_generic
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
instrumentation, but we should only need one config, so that we remove
CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1].
When enable KASAN stack instrumentation, then for gcc we could do no
prompt and default value y, and for clang prompt and default value n.
This patch fixes the following compilation warning:
include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not defined, evaluates to 0 [-Wundef]
[akpm@linux-foundation.org: fix merge snafu]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=210221 [1]
Link: https://lkml.kernel.org/r/20210226012531.29231-1-walter-zh.wu@mediatek.com
Fixes: d9b571c885a8 ("kasan: fix KASAN_STACK dependency for HW_TAGS")
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
gcc-11 adds support for -fsanitize=kernel-hwaddress, so it becomes
possible to enable CONFIG_KASAN_SW_TAGS.
Unfortunately this fails to build at the moment, because the
corresponding command line arguments use llvm specific syntax.
Change it to use the cc-param macro instead, which works on both clang
and gcc.
[elver@google.com: fixup for "kasan: fix hwasan build for gcc"]
Link: https://lkml.kernel.org/r/YHQZVfVVLE/LDK2v@elver.google.com
Link: https://lkml.kernel.org/r/20210323124112.1229772-1-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Marco Elver <elver@google.com>
Reviewed-by: Marco Elver <elver@google.com>
Acked-by: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If the user selects the very first entry in a page and performs a
search-up operation, or selects the very last entry in a page and
performs a search-down operation that will not succeed (e.g., via
[/]asdfzzz[Up Arrow]), nconf will never terminate searching the page.
The reason is that in this case, the starting point will be set to -1
or n, which is then translated into (n - 1) (i.e., the last entry of
the page) or 0 (i.e., the first entry of the page) and finally the
search begins. This continues to work fine until the index reaches 0 or
(n - 1), at which point it will be decremented to -1 or incremented to
n, but not checked against the starting point right away. Instead, it's
wrapped around to the bottom or top again, after which the starting
point check occurs... and naturally fails.
My original implementation added another check for -1 before wrapping
the running index variable around, but Masahiro Yamada pointed out that
the actual issue is that the comparison point (starting point) exceeds
bounds (i.e., the [0,n-1] interval) in the first place and that,
instead, the starting point should be fixed.
This has the welcome side-effect of also fixing the case where the
starting point was n while searching down, which also lead to an
infinite loop.
OTOH, this code is now essentially all his work.
Amazingly, nobody seems to have been hit by this for 11 years - or at
the very least nobody bothered to debug and fix this.
Signed-off-by: Mihai Moldovan <ionic@ionic.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
sphinx-pre-install is picky when it comes to parsing sphinx versions; it
failed when run with sphinx 4.0.0b1. Tweak the regex to tolerate a
trailing "bN" on the version number.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Currently kernel-doc does not identify some cases of probable kernel
doc comments, for e.g. pointer used as declaration type for identifier,
space separated identifier, etc.
Some example of these cases in files can be:
i)" * journal_t * jbd2_journal_init_dev() - creates and initialises a journal structure"
in fs/jbd2/journal.c
ii) "* dget, dget_dlock - get a reference to a dentry" in
include/linux/dcache.h
iii) " * DEFINE_SEQLOCK(sl) - Define a statically allocated seqlock_t"
in include/linux/seqlock.h
Also improve identification for non-kerneldoc comments. For e.g.,
i) " * The following functions allow us to read data using a swap map"
in kernel/power/swap.c does follow the kernel-doc like syntax, but the
content inside does not adheres to the expected format.
Improve parsing by adding support for these probable attempts to write
kernel-doc comment.
Suggested-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/lkml/87mtujktl2.fsf@meer.lwn.net
Signed-off-by: Aditya Srivastava <yashsri421@gmail.com>
Link: https://lore.kernel.org/r/20210414192529.9080-1-yashsri421@gmail.com
[ jc: fixed some line-length issues ]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This helper is the same as the sample code in the NCURSES HOWTO [1],
but it is over-engineering to be used for nconf.
I do not see any good reason to use the 'float' type just for the
division by 2.
All the call-sites pass a non-NULL pointer to the first argument,
so 'if (win == NULL) win = stdscr;' is dead code.
'if (startx != 0) x = startx;' is dead code because 'x' will be
overridden some lines below, by 'x = startx + (int)temp;'.
All the call-sites pass a non-zero value to the second argument,
so 'if (starty != 0)' is always true.
getyx(win, y, x) is also dead-code because both 'y' and 'x' are
overridden.
All the call-sites pass 0 to the third parameter, so 'startx' can
be removed.
All the call-sites pass a non-zero value to the fourth parameter,
so 'if (width == 0) width = 80;' is dead code.
The window will be refreshed later, so there is no need to call
refresh() in this function.
Change the type of the last parameter from 'chtype' to 'int' to be
aligned with the prototype, 'int wattrset(WINDOW *win, int attrs);'
I also slightly cleaned up the indentation style.
[1]: https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/color.html
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This attribute is not used because it will be overridden some lines
below:
wattrset(main_window, attr_main_menu_box);
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The current attributes setup code is strange; the array attribute[]
is set to values outside the range of the attribute_t enum.
At least,
attributes_t attributes[ATTR_MAX+1] = {0};
... should be
int attribute[ATTR_MAX+1] = {0};
Also, there is no need to hard-code the color-pair numbers in
attributes_t.
The current code is messy. Rewrite it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The rootmenu always has a prompt even if the 'mainmenu' statement is
missing in the top Kconfig file.
conf_parse() calls menu_add_prompt(P_MENU, "Main menu", NULL) in this
case.
So, every 'menu' has a prompt.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This reverts commit 10175ba65fde ("nconfig: Silence unused return values
from wattrset").
With this patch applied, recent GCC versions can cleanly build nconf
without "value computed is not used" warnings.
The wattrset() used to be implemented as a macro, like this:
#define wattrset(win,at) \
(NCURSES_OK_ADDR(win) \
? ((win)->_attrs = NCURSES_CAST(attr_t, at), \
OK) \
: ERR)
The GCC bugzilla [1] reported a false-positive -Wunused-value warning
in a similar test case. It was fixed by GCC 4.4.1.
Let's revert that commit, and see if somebody will claim the issue.
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39889
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The lower 8-bit of attributes should be 0, but this code wrongly
sets it to NORMAL (=1). The correct one is A_NORMAL.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
snprintf() always terminates the destination buffer with '\0' even if
the buffer is not long enough. (In this case, the last element of the
buffer becomes '\0'.)
The explicit termination is unneeded.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When the .config file is missing, 'make config', 'make menuconfig', etc.
uses a file listed in DEFCONFIG_LIST, if found, as base configuration.
Ususally, /boot/config-$(uname -r) exists, and is used as default.
However, when you are cross-compiling the kernel, it does not make
sense to use /boot/config-* on the build host. It should default to
arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG).
UML previously did not use DEFCONFIG_LIST at all, but it should be
able to use arch/um/configs/$(KBUILD_DEFCONFIG) as a base config file.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
sym_change_count has no good reason to be 'int' type.
sym_set_change_count() compares the old and new values after casting
both of them to (bool). I do not see any practical diffrence between
sym_set_change_count(1) and sym_add_change_count(1).
Use the boolean flag, conf_changed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The following code in get_mext_match():
index = (index + items_num) % items_num;
... makes the program crash when items_num is zero (that is, the menu
is empty).
A menu can be empty when all the options in it are hidden by unmet
'depends on'.
For example,
menu "This menu will be empty"
config FOO
bool "foo"
depends on BROKEN
endmenu
If you visit this menu and press a '/' key and then another key, nconf
crashes with:
Floating point exception (core dumped)
When the number of items is zero, it does not make sense to search in
the menu. In this case, current_item() returns NULL, and item_index()
ERR, but get_mext_match() does not check it.
Let's make get_mext_match() just return if the menu is empty.
While I am here, change items_num from 'int' to 'unsigned int' because
it should never become negative.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
fixed the following coccicheck:
./scripts/kconfig/confdata.c:36:9-10: WARNING: return of 0/1 in function
'is_dir' with return type bool
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Now "modules" is the only member of the "option" property.
Remove "option", and move "modules" to the top level property.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
