check_conf() never increments conf_cnt for listnewconfig, so conf_cnt
is always zero.
In other words, conf_cnt is not zero, "input_mode != listnewconfig"
is met.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
check_conf() traverses the menu tree, but it is completely no-op for
olddefconfig because the following if-else block does nothing.
if (input_mode == listnewconfig) {
...
} else if (input_mode != olddefconfig) {
...
}
As the help message says, olddefconfig automatically sets new symbols
to their default value. There is no room for manual intervention.
So, calling check_conf() for olddefconfig is odd in the first place.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
=== Background ===
- Visible n-valued bool/tristate symbols generate a
'# CONFIG_FOO is not set' line in the .config file. The idea is to
remember the user selection without having to set a Makefile
variable. Having n correspond to the variable being undefined in the
Makefiles makes for easy CONFIG_* tests.
- Invisible n-valued bool/tristate symbols normally do not generate a
'# CONFIG_FOO is not set' line, because user values from .config
files have no effect on invisible symbols anyway.
Currently, there is one exception to this rule: Any bool/tristate symbol
that gets the value n through a 'default' property generates a
'# CONFIG_FOO is not set' line, even if the symbol is invisible.
Note that this only applies to explicitly given defaults, and not when
the symbol implicitly defaults to n (like bool/tristate symbols without
'default' properties do).
This is inconsistent, and seems redundant:
- As mentioned, the '# CONFIG_FOO is not set' won't affect the symbol
once the .config is read back in.
- Even if the symbol is invisible at first but becomes visible later,
there shouldn't be any harm in recalculating the default value
rather than viewing the '# CONFIG_FOO is not set' as a previous
user value of n.
=== Changes ===
Change sym_calc_value() to only set SYMBOL_WRITE (write to .config) for
non-n-valued 'default' properties.
Note that SYMBOL_WRITE is always set for visible symbols regardless of whether
they have 'default' properties or not, so this change only affects invisible
symbols.
This reduces the size of the x86 .config on my system by about 1% (due
to removed '# CONFIG_FOO is not set' entries).
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:
config FOO
bool
config FOO
bool
default n
With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
This change only affects generated .config files and not autoconf.h:
autoconf.h only includes #defines for non-n bool/tristate symbols.
=== Testing ===
The following testing was done with the x86 Kconfigs:
- .config files generated before and after the change were compared to
verify that the only difference is some '# CONFIG_FOO is not set'
entries disappearing. A couple of these were inspected manually, and
most turned out to be from redundant 'default n/def_bool n'
properties.
- The generated include/generated/autoconf.h was compared before and
after the change and verified to be identical.
- As a sanity check, the same modification was done to Kconfiglib.
The Kconfiglib test suite was then run to check for any mismatches
against the output of the C implementation.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Surprisingly or not, disabling a CONFIG option (which is assumed to
be unneeded) may be not so trivial. Especially it is not trivial, when
this CONFIG option is selected by a dozen of other configs. Before the
moment commit 1ccb271433 ("kconfig: make "Selected by:" and
"Implied by:" readable") popped up in v4.16-rc1, it was an absolute pain
to break down the "Selected by" reverse dependency expression in order
to identify all those configs which select (IOW *do not allow
disabling*) a certain feature (assumed to be not needed).
This patch tries to make one step further by putting at users'
fingertips the revdep top level OR sub-expressions grouped/clustered by
the tristate value they evaluate to. This should allow the users to
directly concentrate on and tackle the _active_ reverse dependencies.
To give some numbers and quantify the complexity of certain reverse
dependencies, assuming commit 617aebe6a9 ("Merge tag
'usercopy-v4.16-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux"), ARCH=arm64
and vanilla arm64 defconfig, here is the top 10 CONFIG options with
the highest amount of top level "||" sub-expressions/tokens that make
up the final "Selected by" reverse dependency expression.
| Config | All revdep | Active revdep |
|-------------------|------------|---------------|
| REGMAP_I2C | 212 | 9 |
| CRC32 | 167 | 25 |
| FW_LOADER | 128 | 5 |
| MFD_CORE | 124 | 9 |
| FB_CFB_IMAGEBLIT | 114 | 2 |
| FB_CFB_COPYAREA | 111 | 2 |
| FB_CFB_FILLRECT | 110 | 2 |
| SND_PCM | 103 | 2 |
| CRYPTO_HASH | 87 | 19 |
| WATCHDOG_CORE | 86 | 6 |
The story behind the above is that users need to visually
review/evaluate 212 expressions which *potentially* select REGMAP_I2C
in order to identify the expressions which *actually* select REGMAP_I2C,
for a particular ARCH and for a particular defconfig used.
To make this experience smoother, change the way reverse dependencies
are displayed to the user from [1] to [2].
[1] Old representation of DMA_ENGINE_RAID:
Selected by:
- AMCC_PPC440SPE_ADMA [=n] && DMADEVICES [=y] && (440SPe || 440SP)
- BCM_SBA_RAID [=m] && DMADEVICES [=y] && (ARM64 [=y] || ...
- FSL_RAID [=n] && DMADEVICES [=y] && FSL_SOC && ...
- INTEL_IOATDMA [=n] && DMADEVICES [=y] && PCI [=y] && X86_64
- MV_XOR [=n] && DMADEVICES [=y] && (PLAT_ORION || ARCH_MVEBU [=y] ...
- MV_XOR_V2 [=y] && DMADEVICES [=y] && ARM64 [=y]
- XGENE_DMA [=n] && DMADEVICES [=y] && (ARCH_XGENE [=y] || ...
- DMATEST [=n] && DMADEVICES [=y] && DMA_ENGINE [=y]
[2] New representation of DMA_ENGINE_RAID:
Selected by [y]:
- MV_XOR_V2 [=y] && DMADEVICES [=y] && ARM64 [=y]
Selected by [m]:
- BCM_SBA_RAID [=m] && DMADEVICES [=y] && (ARM64 [=y] || ...
Selected by [n]:
- AMCC_PPC440SPE_ADMA [=n] && DMADEVICES [=y] && (440SPe || ...
- FSL_RAID [=n] && DMADEVICES [=y] && FSL_SOC && ...
- INTEL_IOATDMA [=n] && DMADEVICES [=y] && PCI [=y] && X86_64
- MV_XOR [=n] && DMADEVICES [=y] && (PLAT_ORION || ARCH_MVEBU [=y] ...
- XGENE_DMA [=n] && DMADEVICES [=y] && (ARCH_XGENE [=y] || ...
- DMATEST [=n] && DMADEVICES [=y] && DMA_ENGINE [=y]
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit splits out the special E_OR handling ('-' instead of '||')
into a dedicated helper expr_print_revdev().
Restore the original expr_print() prior to commit 1ccb271433
("kconfig: make "Selected by:" and "Implied by:" readable").
This makes sense because:
- We need to chop those expressions only when printing the reverse
dependency, and only when E_OR is encountered
- Otherwise, it should be printed as before, so fall back to
expr_print()
This also improves the behavior; for a single line, it was previously
displayed in the same line as "Selected by", like this:
Selected by: A [=n] && B [=n]
This will be displayed in a new line, consistently:
Selected by:
- A [=n] && B [=n]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
IMO, we should discourage '---help---' for new help texts, even in cases
where it would be consistent with other help texts in the file. This
will help if we ever want to get rid of '---help---' in the future.
Also simplify the code to only check for exactly '---help---'. Since
commit c2264564df ("kconfig: warn of unhandled characters in Kconfig
commands"), '---help---' is a proper keyword and can only appear in that
form. Prior to that commit, '---help---' working was more of a syntactic
quirk.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, only Kconfig symbols are checked for a missing or short help
text, and are only checked if they are defined with the 'config'
keyword.
To make the check more general, extend it to also check help texts for
choices and for symbols defined with the 'menuconfig' keyword.
This increases the accuracy of the check for symbols that would already
have been checked as well, since e.g. a 'menuconfig' symbol after a help
text will be recognized as ending the preceding symbol/choice
definition.
To increase the accuracy of the check further, also recognize 'if',
'endif', 'menu', 'endmenu', 'endchoice', and 'source' as ending a
symbol/choice definition.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The check for a missing or short help text only considers symbols with a
prompt, but doesn't recognize any of the following as a prompt:
bool 'foo'
tristate 'foo'
prompt "foo"
prompt 'foo'
Make the check recognize those too.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
With the incremental linking entirely dropped, we can simplify
the Makefile.
While I am here, I renamed cmd_link_o_target to cmd_ar_builtin.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
When built-in.o was incrementally linked with 'ld -r', the section
mismatch analysis for the individual built-in.o was possible when
CONFIG_DEBUG_SECTION_MISMATCH was enabled.
With the migration to the thin archive, built-in.a (former, built-in.o)
is no longer an ELF file. So, the modpost does nothing useful.
scripts/mod/modpost.c just checks the header to bail out, as follows:
/* Is this a valid ELF file? */
if ((hdr->e_ident[EI_MAG0] != ELFMAG0) ||
(hdr->e_ident[EI_MAG1] != ELFMAG1) ||
(hdr->e_ident[EI_MAG2] != ELFMAG2) ||
(hdr->e_ident[EI_MAG3] != ELFMAG3)) {
/* Not an ELF file - silently ignore it */
return 0;
}
We have the full analysis in the final link stage anyway, so we would
not miss the section mismatching.
I do not see a good reason to require extra linking only for the
purpose of the per-directory analysis. Just get rid of this part.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
In Kbuild, Makefiles can add the same object to obj-y multiple
times. So,
obj-y += foo.o
obj-y += foo.o
is fine.
However, this is not true when the same object is added multiple
times via composite objects. For example,
obj-y += foo.o bar.o
foo-objs := foo-bar-common.o foo-only.o
bar-objs := foo-bar-common.o bar-only.o
causes build error because two instances of foo-bar-common.o are
linked into the vmlinux.
Makefiles tend to invent ugly work-around, for example
- lib/zstd/Makefile
- drivers/net/ethernet/cavium/liquidio/Makefile
The technique used in Kbuild to avoid the multiple definition error
is to use $(filter $(obj-y), $^). Here, $^ lists the names of all
the prerequisites with duplicated names removed.
By replacing it with $(filter $(real-obj-y), $^) we can do likewise
for composite objects. For built-in objects, we do not need to keep
the composite object structure. We can simply expand them, and link
$(real-obj-y) to built-in.a.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
When I was refactoring Makefiles, I stupidly mistook 'real-obj-y' for
'real-objs-y' over and over again. Finally, I decide to rename it to
'real-obj-y'. This is consistent with 'obj-y', 'subdir-obj-y'.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
modname can be calculated much more simply. If modname-multi is
empty, it is a single-used object. So, modname = $(basetarget).
Otherwise, modname = $(modname-multi).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Commit cf4f21938e ("kbuild: Allow to specify composite modules
with modname-m") added modname-m support, but missed to update the
corresponding multi-objs-m & modname-multi definition.
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, KBUILD_MODNAME is defined only when $(modname) contains
just one word. If an object is shared among multiple modules,
undefined KBUILD_MODNAME could cause a build error. For example,
if CONFIG_DYNAMIC_DEBUG is enabled, any call of printk() populates
.modname, then fails to build due to undefined KBUILD_MODNAME.
Take the following code as an example:
obj-m += foo.o
obj-m += bar.o
foo-objs := foo-bar-common.o foo-only.o
bar-objs := foo-bar-common.o bar-only.o
In this case, there is room for argument what to define for
KBUILD_MODNAME when foo-bar-common.o is being compiled.
"foo", "bar", or what else?
One idea is to define colon-separated modules that share the object,
in this case, "bar:foo" (modules are sorted alphabetically by
$(sort ...)).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Cao jin <caoj.fnst@cn.fujitsu.com>
In the context ...
$(obj)/%.s: $(src)/%.c FORCE
$(call if_changed_dep,cc_s_c)
$(obj)/%.i: $(src)/%.c FORCE
$(call if_changed_dep,cpp_i_c)
$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
$(obj)/%.lst: $(src)/%.c FORCE
$(call if_changed_dep,cc_lst_c)
'$*' returns the stem of the target (the part of '%'), so $(obj)/ has
already been ripped off.
$(subst $(obj)/,,$*.o) is the same as $*.o
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Cao jin <caoj.fnst@cn.fujitsu.com>
stat(1) is not standardized and different implementations have their own
(conflicting) flags for querying the size of a file.
ls(1) provides the same information (value of st.st_size) in the 5th
column, except when the file is a character or block device. This output
is standardized[0]. The -n option turns on -l, which writes lines
formatted like
"%s %u %s %s %u %s %s\n", <file mode>, <number of links>,
<owner name>, <group name>, <size>, <date and time>,
<pathname>
but instead of writing the <owner name> and <group name>, it writes the
numeric owner and group IDs (this avoids /etc/passwd and /etc/group
lookups as well as potential field splitting issues).
The <size> field is specified as "the value that would be returned for
the file in the st_size field of struct stat".
To avoid duplicating logic in several locations in the tree, create
scripts/file-size.sh and update callers to use that instead of stat(1).
[0] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html#tag_20_73_10
Signed-off-by: Michael Forney <forney@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The idea of using fixdep was inspired by Kconfig, but autoksyms
belongs to a different group. So, I want to move those touched
files under include/config/ksym/ to include/ksym/.
The directory include/ksym/ can be removed by 'make clean' because
it is meaningless for the external module building.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Commit d3fc425e81 ("kbuild: make sure autoksyms.h exists early")
moved the code that touches autoksyms.h to scripts/kconfig/Makefile
with obscure reason.
From Nicolas' comment [1], he did not seem to be sure about the root
cause.
I guess I figured it out, so here is a fix-up I think is more correct.
According to the error log in the original post [2], the build failed
in scripts/mod/devicetable-offsets.c
scripts/mod/Makefile is descended from scripts/Makefile, which is
invoked from the top-level Makefile by the 'scripts' target.
To build vmlinux and/or modules, Kbuild descend into $(vmlinux-dirs).
This depends on 'prepare' and 'scripts' as follows:
$(vmlinux-dirs): prepare scripts
Because there is no dependency between 'prepare' and 'scripts', the
parallel building can execute them simultaneously.
'prepare' depends on 'prepare1', which touched autoksyms.h, while
'scripts' descends into script/, then scripts/mod/, which needs
<generated/autoksyms.h> if CONFIG_TRIM_UNUSED_KSYMS. It was the
reason of the race.
I am not happy to have unrelated code in the Kconfig Makefile, so
getting it back to the top Makefile.
I removed the standalone test target because I want to use it to
create an empty autoksyms.h file. Here is a little improvement;
unnecessary autoksyms.h is not created when CONFIG_TRIM_UNUSED_KSYMS
is disabled.
[1] https://lkml.org/lkml/2016/11/30/734
[2] https://lkml.org/lkml/2016/11/30/531
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
The comment mentions it creates autoksyms.h in case it is missing,
but the actual code touches it when it does exists.
The build system creates it anyway because <linux/export.h> and
<asm-generic/export.h> need it.
The code would not have worked as intended, and people have not
noticed it. This is a proof that we can simply remove it.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Currently, linker options are tested by the coordination of $(CC) and
$(LD) because $(LD) needs some object to link.
As commit 86a9df597c ("kbuild: fix linker feature test macros when
cross compiling with Clang") addressed, we need to make sure $(CC)
and $(LD) agree the underlying architecture of the passed object.
This could be a bit complex when we combine tools from different groups.
For example, we can use clang for $(CC), but we still need to rely on
GCC toolchain for $(LD).
So, I was searching for a way of standalone testing of linker options.
A trick I found is to use '-v'; this not only prints the version string,
but also tests if the given option is recognized.
If a given option is supported,
$ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419
GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706
$ echo $?
0
If unsupported,
$ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419
GNU ld (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 2.23.1
aarch64-linux-gnu-ld: unrecognized option '--fix-cortex-a53-843419'
aarch64-linux-gnu-ld: use the --help option for usage information
$ echo $?
1
Gold works likewise.
$ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-843419
GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14
masahiro@pug:~/ref/linux$ echo $?
0
$ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-999999
GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14
aarch64-linux-gnu-ld.gold: --fix-cortex-a53-999999: unknown option
aarch64-linux-gnu-ld.gold: use the --help option for usage information
$ echo $?
1
LLD too.
$ ld.lld -v --gc-sections
LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
$ echo $?
0
$ ld.lld -v --fix-cortex-a53-843419
LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
$ echo $?
0
$ ld.lld -v --fix-cortex-a53-999999
ld.lld: error: unknown argument: --fix-cortex-a53-999999
LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
$ echo $?
1
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Incremental linking is gone, so rename built-in.o to built-in.a, which
is the usual extension for archive files.
This patch does two things, first is a simple search/replace:
git grep -l 'built-in\.o' | xargs sed -i 's/built-in\.o/built-in\.a/g'
The second is to invert nesting of nested text manipulations to avoid
filtering built-in.a out from libs-y2:
-libs-y2 := $(filter-out %.a, $(patsubst %/, %/built-in.a, $(libs-y)))
+libs-y2 := $(patsubst %/, %/built-in.a, $(filter-out %.a, $(libs-y)))
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
