Like modules_install, modules_sign should avoid the syncconfig.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Commit 961ab4a3cd ("kbuild: merge scripts/Makefile.modsign to
scripts/Makefile.modinst") started to run depmod at the end of
'make modules_sign'.
Move the depmod rule to scripts/Makefile.modinst and run it only when
$(modules_sign_only) is empty.
Fixes: 961ab4a3cd ("kbuild: merge scripts/Makefile.modsign to scripts/Makefile.modinst")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
'make srcdeb-pkg' generates a source package, which you can build
later by using dpkg-buildpackage.
In older dpkg versions, 'dpkg-buildpackage --jobs=N' sets not only
DEB_BUILD_OPTIONS but also MAKEFLAGS. Hence, passing -j or --jobs
to dpkg-buildpackage was enough for kicking the parallel execution.
The behavior was changed by commit 1d0ea9b2ba3f ("dpkg-buildpackage:
Change -j, --jobs semantics to non-force mode") of dpkg project. [1]
Since then, 'dpkg-buildpackage --jobs=N' sets only DEB_BUILD_OPTIONS,
which is not parsed by the current debian/rules. To build the package
in parallel, you need to pass the alternative --jobs-force option or
set the MAKEFLAGS environment variable.
Debian policy [2] suggests the following code snippet for debian/rules.
ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
MAKEFLAGS += -j$(NUMJOBS)
endif
I tweaked the code to filter out parallel=1 and passed --jobs=1 to
dpkg-buildpackage from scripts/Makefile.package. It is needed to force
'make deb-pkg' without the -j option to run in serial. Please note that
dpkg-buildpackage sets parallel=<nproc> in DEB_BUILD_OPTIONS by default
(that is, --jobs=auto is the default) and --jobs=1 is needed to restore
the serial execution. When dpkg-buildpackage is invoked from Kbuild,
the number of jobs is inherited from the top level Makefile. Passing
--jobs=1 to dpkg-buildpackage allows debian/rules to skip parsing
DEB_BUILD_OPTIONS.
[1] 1d0ea9b2ba
[2] https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options
Reported-by: Bastian Germann <bage@linutronix.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
All *.S files under arch/alpha/ have been converted to include
<linux/export.h> instead of <asm/export.h>.
Remove <asm/export.h>.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit ddb5cdbafa ("kbuild: generate KSYMTAB entries by modpost")
deprecated <asm/export.h>, which is now a wrapper of <linux/export.h>.
Replace #include <asm/export.h> with #include <linux/export.h>.
After all the <asm/export.h> lines are converted, <asm/export.h> and
<asm-generic/export.h> will be removed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
All *.S files under arch/ia64/ have been converted to include
<linux/export.h> instead of <asm/export.h>.
Remove <asm/export.h>.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit ddb5cdbafa ("kbuild: generate KSYMTAB entries by modpost")
deprecated <asm/export.h>, which is now a wrapper of <linux/export.h>.
Replace #include <asm/export.h> with #include <linux/export.h>.
After all the <asm/export.h> lines are converted, <asm/export.h> and
<asm-generic/export.h> will be removed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
All *.S files under arch/sparc/ have been converted to include
<linux/export.h> instead of <asm/export.h>.
Remove <asm/export.h>.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Commit ddb5cdbafa ("kbuild: generate KSYMTAB entries by modpost")
deprecated <asm/export.h>, which is now a wrapper of <linux/export.h>.
Replace #include <asm/export.h> with #include <linux/export.h>.
After all the <asm/export.h> lines are converted, <asm/export.h> and
<asm-generic/export.h> will be removed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
This is a remnant of commit 5e9e95cc91 ("kbuild: implement
CONFIG_TRIM_UNUSED_KSYMS without recursion").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Add scripts for generating initramfs to KBUILD, to prevent idling of
patches for usr/.
Signed-off-by: Nicolas Schier <n.schier@avm.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
There are few of these, so enable them whenever W=1 is enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The stringop and format warnings got disabled globally when they were
newly introduced in commit bd664f6b3e ("disable new gcc-7.1.1 warnings
for now"), 217c3e0196 ("disable stringop truncation warnings for now")
and 5a76021c2e ("gcc-10: disable 'stringop-overflow' warning for now").
In all cases, the sentiment at the time was that the warnings are
useful, and we actually addressed a number of real bugs based on
them, but we never managed to eliminate them all because even the
build bots using W=1 builds only see the -Wstringop-truncation
warnings that are enabled at that level.
Move these into the W=1 section to give them a larger build coverage
and actually eliminate them over time.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Some warning options are disabled at one place and then conditionally
re-enabled later in scripts/Makefile.extrawarn.
For consistency, rework this file so each of those warnings only
gets etiher enabled or disabled based on the W= flags but not both.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Warning options are enabled and disabled in inconsistent ways and
inconsistent locations. Start rearranging those by moving all options
into Makefile.extrawarn.
This should not change any behavior, but makes sure we can group them
in a way that ensures that each warning that got temporarily disabled
is turned back on at an appropriate W=1 level later on.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested with Qt5 5.15 and Qt6 6.4. Note that earlier versions of Qt5
are no longer guaranteed to work.
Signed-off-by: Boris Kolpackov <boris@codesynthesis.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Menuconfig has a feature where you can "press the key in the (#) prefix
to jump directly to that location. You will be returned to the current
search results after exiting this new menu."
This feature is poorly documented,
so add it to the kconfig.rst documentation.
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Menuconfig has a feature where you can "press the key in the (#) prefix
to jump directly to that location. You will be returned to the current
search results after exiting this new menu."
This commit adds this feature to nconfig, with almost identical code.
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit 6ab7e1f95e ("setlocalversion: use only the correct release
tag for git-describe") was absolutely correct to limit which annotated
tags would be used to compute the -01234-gabcdef suffix. Otherwise, if
some random annotated tag exists closer to HEAD than the vX.Y.Z one,
the commit count would be too low.
However, since the version string always includes the
${file_localversion} part, now the problem is that the count can be
too high. For example, building an 6.4.6-rt8 kernel with a few patches
on top, I currently get
$ make -s kernelrelease
6.4.6-rt8-00128-gd78b7f406397
But those 128 commits include the 100 commits that are in
v6.4.6..v6.4.6-rt8, so this is somewhat misleading.
Amend the logic so that, in addition to the linux-next consideration,
the script also looks for a tag corresponding to the 6.4.6-rt8 part of
what will become the `uname -r` string. With this patch (so 29 patches
on top of v6.4.6-rt8), one instead gets
$ make -s kernelrelease
6.4.6-rt8-00029-gd533209291a2
While there, note that the line
git describe --exact-match --match=$tag $tag 2>/dev/null
obviously asks if $tag is an annotated tag, but it does not actually
tell if the commit pointed to has any relation to HEAD. So remove both
uses of --exact-match, and instead just ask if the description
generated is identical to the tag we provided. Since we then already
have the result of
git describe --match=$tag
we also end up reducing the number of times we invoke "git describe".
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Nobody has complained since 2a73cce2da ("scripts/setlocalversion:
remove mercurial, svn and git-svn supports"), so let's also clean up
the header comment accordingly.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
debian/rules is generated by shell, but the escape sequence (\$) is
unreadable.
debian/rules embeds only two variables (ARCH and KERNELRELEASE).
Split them out to debian/rules.vars, and check-in the rest of Makefile
code to scripts/package/debian/rules.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Debian Policy "4.9. Main building script: debian/rules" requires
"debian/rules must start with the line #!/usr/bin/make -f". [1]
Currently, Kbuild does not follow this policy.
When Kbuild generates debian/rules, "#!$(command -v $MAKE) -f" is
expanded by shell. The resuling string may not be "#!/usr/bin/make -f".
There was a reason to opt out the Debian policy.
If you run '/path/to/my/custom/make deb-pkg', debian/rules must also be
invoked by the same Make program. If #!/usr/bin/make were hard-coded in
debian/rules, the sub-make would be executed by a possibly different
Make version.
This is problematic due to the MAKEFLAGS incompatibility, especially the
job server flag. Old Make versions used --jobserver-fds to propagate job
server file descriptors, but Make >= 4.2 uses --jobserver-auth. The flag
disagreement between the parent/child Makes would result in a process
fork explosion.
However, having a non-standard path in the shebang causes another issue;
the generated source package is not portable as such a path does not
exist in other build environments.
This commit solves those conflicting demands.
Hard-code '#!/usr/bin/make -f' in debian/rules to create a portable and
Debian-compliant source package.
Pass '--rules-file=$(MAKE) -f debian/rules' when dpkg-buildpackage is
invoked from Makefile so that debian/rules is executed by the same Make
program as used to start Kbuild.
[1] https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Remove the Elf_Rela variables used in the for-loop in section_rel().
This makes the code consistent; section_rel() only uses Elf_Rel,
section_rela() only uses Elf_Rela.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
MIPS64 little endian target has an odd encoding of r_info.
This commit makes the special handling less ugly. It is still ugly,
but #if conditionals will go away, at least.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
All of addend_*_rel() need the Elf_Rela pointer just for calculating
ELF_R_TYPE(r->r_info).
You can do it on the caller to de-duplicate the code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Now that none of addend_*_rel() returns a meaningful value (the return
value is always 0), change all of them to return the value of r_addend.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit 8818039f95 ("kbuild: add ability to make source rpm buildable
using koji") added the BuildRequires: field.
Checking the build dependency is fine, but one annoyance is that
'make (bin)rpm-pkg' fails on non-rpm systems [1]. For example, Debian
provides rpmbuild via 'apt install rpm', but of course cannot meet the
requirement listed in the BuildRequires: field.
It is possible to pass RPMOPTS=--nodeps to work around it, but it is
reasonable to do it automatically.
If 'rpm -q rpm' fails, it is not an RPM-managed system. (The command
'rpm' is not installed at all, or was installed by other means.)
In that case, pass --nodeps to skip the build dependency check.
[1]: https://lore.kernel.org/linux-kbuild/Y6mkdYQYmjUz7bqV@li-4a3a4a4c-28e5-11b2-a85c-a8d192c6f089.ibm.com/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Merge the similar build targets.
Also, make the output location consistent.
Previously, source packages were created in the build directory,
while binary packages under ~/rpmbuild/RPMS/.
Now, Kbuild creates the rpmbuild/ directory in the build directory,
and saves all packages under it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, 'make rpm-pkg' always builds the kernel from the pristine
source tree in the ~/rpmbuild/BUILD/ directory.
Build the kernel incrementally just like 'make binrpm-pkg'.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Now kernel.spec and binkernel.spec have the exactly same contents.
Use kernel.spec for binrpm-pkg as well.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Most of the lines in the spec file are independent of any build
condition.
Split the body of the spec file into scripts/package/kernel.spec.
scripts/package/mkspec will prepend some env-dependent variables.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
scripts/package/mkspec preprocesses the spec file by sed, but it is
unreadable. This commit removes the last portion of the sed scripting.
Remove the $S$M prefixes from the conditionally generated lines.
Instead, surround the code with %if %{with_devel} ... %endif.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
For the same reason as commit 4243afdb93 ("kbuild: builddeb: always
make modules_install, to install modules.builtin*"), run modules_install
even when CONFIG_MODULES=n to install modules.builtin*.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
To reduce the preprocess of the spec file, invoke the kernel build
from rpmbuild.
Run init/build-version to increment the release number not only for
binrpm-pkg but also for srcrpm-pkg and rpm-pkg.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
If this affects only %{buildroot}, it should be enough to use a fixed
string for _arch when it is undefined.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The kernel-devel RPM package and the linux-headers Debian package
provide headers and scripts needed for building external modules.
They copy the necessary files in slightly different ways - the RPM
copies almost everything except some exclude patterns, while the Debian
copies less number of files. There is no need to maintain different code
to do the same thing.
Split the Debian code out to scripts/package/install-extmod-build, which
is called from both of the packages.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
There are some cases where we want to run a command with the same
environment variables as Kbuild uses. For example, 'make coccicheck'
invokes scripts/coccicheck from the top Makefile so that the script can
reference to ${LINUXINCLUDE}, ${KBUILD_EXTMOD}, etc. The top Makefile
defines several phony targets that run a script.
We do it also for an internally used script, which results in a somewhat
complex call graph.
One example:
debian/rules binary-arch
-> make intdeb-pkg
-> scripts/package/builddeb
It is also tedious to add a dedicated target like 'intdeb-pkg' for each
use case.
Add a generic target 'run-command' to run an arbitrary command in an
environment with all Kbuild variables set.
The usage is:
$ make run-command KBUILD_RUN_COMMAND=<command>
The concept is similar to:
$ dpkg-architecture -c <command>
This executes <command> in an environment which has all DEB_* variables
defined.
Convert the existing 'make intdeb-pkg'.
Another possible usage is to interrogate a Make variable.
$ make run-command KBUILD_RUN_COMMAND='echo $(KBUILD_CFLAGS)'
might be useful to see KBUILD_CFLAGS set by the top Makefile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, we rely on the top Makefile defining ARCH option when we
run 'make rpm-pkg' or 'make binrpm-pkg'.
It does not apply when we run 'make srcrpm-pkg', and separately run
'rpmbuild' for the generated SRPM. This is a problem for cross-build.
Just like the Debian package, save the value of ARCH in the spec file.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, $MAKE will expand to the GNU Make program that created the
source RPM. This is problematic if you carry it to a different build
host to run 'rpmbuild' there.
Consider this command:
$ /path/to/my/custom/make srcrpm-pkg
The spec file in the SRPM will record '/path/to/my/custom/make', which
exists only on that build environment.
To create a portable SRPM, the spec file should avoid hard-coding $MAKE.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This is unneeded because the Makefile in the output directory wraps
the top-level Makefile in the srctree.
Just run $MAKE irrespective of the build location.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit 3089b2be0c ("kbuild: rpm-pkg: fix build error when _arch is
undefined") does not work as intended; _arch is always defined as
$UTS_MACHINE.
The intention was to define _arch to $UTS_MACHINE only when it is not
defined.
Fixes: 3089b2be0c ("kbuild: rpm-pkg: fix build error when _arch is undefined")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Remove hack for ancient version of module-init-tools that was added in
Linux 3.0.
Since then module-init-tools was replaced with kmod.
This hack adds an additional indirection, and causes confusing errors
to be printed when depmod fails.
Reverts commit 8fc62e5942 ("kbuild: Do not write to builddir in modules_install")
Reverts commit bfe5424a8b ("kbuild: Hack for depmod not handling X.Y versions")
Link: https://lore.kernel.org/linux-modules/CAK7LNAQMs3QBYfWcLkmOQdbbq7cj=7wWbK=AWhdTC2rAsKHXzQ@mail.gmail.com/
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
You do not need to remember the index of each jump key because you can
count it up after a key is pressed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Jesse Taube <Mr.Bossman075@gmail.com>
Commit 95ac9b3b58 ("menuconfig: Assign jump keys per-page instead
of globally") injected a lot of hacks to the bottom of the textbox
infrastructure.
I reverted many of them without changing the behavior. (almost)
Now, the key markers are inserted when constructing the search result
instead of updating the text buffer on-the-fly.
The buffer passed to the textbox got back to a constant string.
The ugly casts from (const char *) to (char *) went away.
A disadvantage is that the same key numbers might be displayed multiple
times in the dialog if you use a huge window (but I believe it is
unlikely to happen).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Jesse Taube <Mr.Bossman075@gmail.com>
Currently, all files with EXPORT_SYMBOL() are rebuilt when CONFIG_MODULES
is flipped due to <linux/export.h> depending on CONFIG_MODULES.
Now that modpost can make a final decision about export symbols,
<linux/export.h> does not need to make EXPORT_SYMBOL() no-op.
Instead, modpost can skip emitting KSYMTAB when CONFIG_MODULES is unset.
This commit will reduce the number of recompilation when CONFIG_MODULES
is toggled.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This diagnostic checks whether there is a type mismatch when
converting enums (assign an enum of type A to an enum of type B, for
example) and it caught a legit issue recently. The reason it didn't show
is because that warning is enabled only with -Wextra with GCC. Clang,
however, enables it by default.
GCC folks were considering enabling it by default but it was too noisy
back then:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
Now that due to clang all those warnings have been fixed, enable it with
GCC too.
allmodconfig tests done with: x86, arm{,64}, powerpc{,64}, riscv
crossbuilds.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada