People trying out the Rust support in the kernel may get
warnings and errors from `scripts/rust_is_available.sh`
from the `rustavailable` target or the build step.
Some of those users may be following the Quick Start guide,
but others may not (likely those getting warnings from
the build step instead of the target).
While the messages are fairly clear on what the problem is,
it may not be clear how to solve the particular issue,
especially for those not aware of the documentation.
We could add all sorts of details on the script for each one,
but it is better to point users to the documentation instead,
where it is easily readable in different formats. It also
avoids duplication.
Thus add a reference to the documentation whenever the script
fails or there is at least a warning.
Reviewed-by: Finn Behrens <fin@nyantec.com>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Link: https://lore.kernel.org/r/20230616001631.463536-5-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
rust_is_available.sh uses cc-version.sh to identify which C compiler is
in use, as scripts/Kconfig.include does. cc-version.sh isn't designed to
be able to handle multiple arguments in one variable, i.e. "ccache clang".
Its invocation in rust_is_available.sh quotes "$CC", which makes
$1 == "ccache clang" instead of the intended $1 == ccache & $2 == clang.
cc-version.sh could also be changed to handle having "ccache clang" as one
argument, but it only has the one consumer upstream, making it simpler to
fix the caller here.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Fixes: 78521f3399 ("scripts: add `rust_is_available.sh`")
Link: https://github.com/Rust-for-Linux/linux/pull/873
[ Reworded title prefix and reflow line to 75 columns. ]
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20230616001631.463536-3-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@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>
Adds support for out-of-tree rust modules to use the `rust-analyzer`
make target to generate the rust-project.json file.
The change involves adding an optional parameter `external_src` to the
`generate_rust_analyzer.py` which expects the path to the out-of-tree
module's source directory. When this parameter is passed, I have chosen
not to add the non-core modules (samples and drivers) into the result
since these are not expected to be used in third party modules. Related
changes are also made to the Makefile and rust/Makefile allowing the
`rust-analyzer` target to be used for out-of-tree modules as well.
Link: https://github.com/Rust-for-Linux/linux/pull/914
Link: https://github.com/Rust-for-Linux/rust-out-of-tree-module/pull/2
Signed-off-by: Vinay Varma <varmavinaym@gmail.com>
Link: https://lore.kernel.org/r/20230411091714.130525-1-varmavinaym@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
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>
Pull kvm fixes from Paolo Bonzini:
"x86:
- Do not register IRQ bypass consumer if posted interrupts not
supported
- Fix missed device interrupt due to non-atomic update of IRR
- Use GFP_KERNEL_ACCOUNT for pid_table in ipiv
- Make VMREAD error path play nice with noinstr
- x86: Acquire SRCU read lock when handling fastpath MSR writes
- Support linking rseq tests statically against glibc 2.35+
- Fix reference count for stats file descriptors
- Detect userspace setting invalid CR0
Non-KVM:
- Remove coccinelle script that has caused multiple confusion
("debugfs, coccinelle: check for obsolete DEFINE_SIMPLE_ATTRIBUTE()
usage", acked by Greg)"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (21 commits)
KVM: selftests: Expand x86's sregs test to cover illegal CR0 values
KVM: VMX: Don't fudge CR0 and CR4 for restricted L2 guest
KVM: x86: Disallow KVM_SET_SREGS{2} if incoming CR0 is invalid
Revert "debugfs, coccinelle: check for obsolete DEFINE_SIMPLE_ATTRIBUTE() usage"
KVM: selftests: Verify stats fd is usable after VM fd has been closed
KVM: selftests: Verify stats fd can be dup()'d and read
KVM: selftests: Verify userspace can create "redundant" binary stats files
KVM: selftests: Explicitly free vcpus array in binary stats test
KVM: selftests: Clean up stats fd in common stats_test() helper
KVM: selftests: Use pread() to read binary stats header
KVM: Grab a reference to KVM for VM and vCPU stats file descriptors
selftests/rseq: Play nice with binaries statically linked against glibc 2.35+
Revert "KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"
KVM: x86: Acquire SRCU read lock when handling fastpath MSR writes
KVM: VMX: Use vmread_error() to report VM-Fail in "goto" path
KVM: VMX: Make VMREAD error path play nice with noinstr
KVM: x86/irq: Conditionally register IRQ bypass consumer again
KVM: X86: Use GFP_KERNEL_ACCOUNT for pid_table in ipiv
KVM: x86: check the kvm_cpu_get_interrupt result before using it
KVM: x86: VMX: set irr_pending in kvm_apic_update_irr
...
getline() returns -1 at EOF as well as on error. It also doesn't set
errno to 0 on success, so initialize it to 0 before using errno to check
for an error condition. See the paragraph here [1]:
For some system calls and library functions (e.g., getpriority(2)),
-1 is a valid return on success. In such cases, a successful return
can be distinguished from an error return by setting errno to zero
before the call, and then, if the call returns a status that indicates
that an error may have occurred, checking to see if errno has a
nonzero value.
Bear has a bug [2] that launches processes with errno set and causes the
following build failure:
$ bear -- make LLVM=1
...
LD .tmp_vmlinux.kallsyms1
NM .tmp_vmlinux.kallsyms1.syms
KSYMS .tmp_vmlinux.kallsyms1.S
read_symbol: Invalid argument
[1]: https://linux.die.net/man/3/errno
[2]: https://github.com/rizsotto/Bear/issues/469
Fixes: 1c975da56a ("scripts/kallsyms: remove KSYM_NAME_LEN_BUFFER")
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: James Clark <james.clark@arm.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
RCU Tasks Trace is quite specialized, having been created specifically
for sleepable BPF programs. Because it allows general blocking within
readers, any new use of RCU Tasks Trace must take current use cases into
account. Therefore, update checkpatch.pl to complain about use of any of
the RCU Tasks Trace API members outside of BPF and outside of RCU itself.
[ paulmck: Apply Joe Perches feedback. ]
Cc: Andy Whitcroft <apw@canonical.com> (maintainer:CHECKPATCH)
Cc: Joe Perches <joe@perches.com> (maintainer:CHECKPATCH)
Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> (reviewer:CHECKPATCH)
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: <bpf@vger.kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@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>
