summaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)Author
2024-11-04kconfig: qconf: set QSplitter orientation in the constructorMasahiro Yamada
The orientation of the QSplitter can be specified directly in its constructor. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-04kconfig: remove zconfprint()Masahiro Yamada
Turn all warnings during parsing into hard errors. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-04kconfig: remove support for "bool" prompt for choice entriesMasahiro Yamada
Since commit fde192511bdb ("kconfig: remove tristate choice support"), all choice blocks are now boolean. There is no longer a need to specify the choice type explicitly. All "bool" prompts in choice entries have been converted to "prompt". This commit removes support for the "bool" syntax in choice entries. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-04kbuild: add generic support for built-in boot DTBsMasahiro Yamada
Some architectures embed boot DTBs in vmlinux. A potential issue for these architectures is a race condition during parallel builds because Kbuild descends into arch/*/boot/dts/ twice. One build thread is initiated by the 'dtbs' target, which is a prerequisite of the 'all' target in the top-level Makefile: ifdef CONFIG_OF_EARLY_FLATTREE all: dtbs endif For architectures that support the built-in boot dtb, arch/*/boot/dts/ is visited also during the ordinary directory traversal in order to build obj-y objects that wrap DTBs. Since these build threads are unaware of each other, they can run simultaneously during parallel builds. This commit introduces a generic build rule to scripts/Makefile.vmlinux to support embedded boot DTBs in a race-free way. Architectures that want to use this rule need to select CONFIG_GENERIC_BUILTIN_DTB. After the migration, Makefiles under arch/*/boot/dts/ will be visited only once to build only *.dtb files. This change also aims to unify the CONFIG options used for built-in DTBs support. Currently, different architectures use different CONFIG options for the same purposes. With this commit, the CONFIG options will be unified as follows: - CONFIG_GENERIC_BUILTIN_DTB This enables the generic rule for built-in boot DTBs. This will be renamed to CONFIG_BUILTIN_DTB after all architectures migrate to the generic rule. - CONFIG_BUILTIN_DTB_NAME This specifies the path to the embedded DTB. (relative to arch/*/boot/dts/) - CONFIG_BUILTIN_DTB_ALL If this is enabled, all DTB files compiled under arch/*/boot/dts/ are embedded into vmlinux. Only used by MIPS. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-03Merge tag 'kbuild-fixes-v6.12-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Fix a memory leak in modpost - Resolve build issues when cross-compiling RPM and Debian packages - Fix another regression in Kconfig - Fix incorrect MODULE_ALIAS() output in modpost * tag 'kbuild-fixes-v6.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: modpost: fix input MODULE_DEVICE_TABLE() built for 64-bit on 32-bit host modpost: fix acpi MODULE_DEVICE_TABLE built with mismatched endianness kconfig: show sub-menu entries even if the prompt is hidden kbuild: deb-pkg: add pkg.linux-upstream.nokerneldbg build profile kbuild: deb-pkg: add pkg.linux-upstream.nokernelheaders build profile kbuild: rpm-pkg: disable kernel-devel package when cross-compiling sumversion: Fix a memory leak in get_src_version()
2024-11-03modpost: fix input MODULE_DEVICE_TABLE() built for 64-bit on 32-bit hostMasahiro Yamada
When building a 64-bit kernel on a 32-bit build host, incorrect input MODULE_ALIAS() entries may be generated. For example, when compiling a 64-bit kernel with CONFIG_INPUT_MOUSEDEV=m on a 64-bit build machine, you will get the correct output: $ grep MODULE_ALIAS drivers/input/mousedev.mod.c MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*110,*r*0,*1,*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*r*8,*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*14A,*r*a*0,*1,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*145,*r*a*0,*1,*18,*1C,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*110,*r*a*0,*1,*m*l*s*f*w*"); However, building the same kernel on a 32-bit machine results in incorrect output: $ grep MODULE_ALIAS drivers/input/mousedev.mod.c MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*110,*130,*r*0,*1,*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*r*8,*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*14A,*16A,*r*a*0,*1,*20,*21,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*145,*165,*r*a*0,*1,*18,*1C,*20,*21,*38,*3C,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*110,*130,*r*a*0,*1,*20,*21,*m*l*s*f*w*"); A similar issue occurs with CONFIG_INPUT_JOYDEV=m. On a 64-bit build machine, the output is: $ grep MODULE_ALIAS drivers/input/joydev.mod.c MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*0,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*2,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*8,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*6,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*120,*r*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*130,*r*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*2C0,*r*a*m*l*s*f*w*"); However, on a 32-bit machine, the output is incorrect: $ grep MODULE_ALIAS drivers/input/joydev.mod.c MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*0,*20,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*2,*22,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*8,*28,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*6,*26,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*11F,*13F,*r*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*11F,*13F,*r*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*2C0,*2E0,*r*a*m*l*s*f*w*"); When building a 64-bit kernel, BITS_PER_LONG is defined as 64. However, on a 32-bit build machine, the constant 1L is a signed 32-bit value. Left-shifting it beyond 32 bits causes wraparound, and shifting by 31 or 63 bits makes it a negative value. The fix in commit e0e92632715f ("[PATCH] PATCH: 1 line 2.6.18 bugfix: modpost-64bit-fix.patch") is incorrect; it only addresses cases where a 64-bit kernel is built on a 64-bit build machine, overlooking cases on a 32-bit build machine. Using 1ULL ensures a 64-bit width on both 32-bit and 64-bit machines, avoiding the wraparound issue. Fixes: e0e92632715f ("[PATCH] PATCH: 1 line 2.6.18 bugfix: modpost-64bit-fix.patch") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-03modpost: fix acpi MODULE_DEVICE_TABLE built with mismatched endiannessMasahiro Yamada
When CONFIG_SATA_AHCI_PLATFORM=m, modpost outputs incorect acpi MODULE_ALIAS() if the endianness of the target and the build machine do not match. When the endianness of the target kernel and the build machine match, the output is correct: $ grep 'MODULE_ALIAS("acpi' drivers/ata/ahci_platform.mod.c MODULE_ALIAS("acpi*:APMC0D33:*"); MODULE_ALIAS("acpi*:010601:*"); However, when building a little-endian kernel on a big-endian machine (or vice versa), the output is incorrect: $ grep 'MODULE_ALIAS("acpi' drivers/ata/ahci_platform.mod.c MODULE_ALIAS("acpi*:APMC0D33:*"); MODULE_ALIAS("acpi*:0601??:*"); The 'cls' and 'cls_msk' fields are 32-bit. DEF_FIELD() must be used instead of DEF_FIELD_ADDR() to correctly handle endianness of these 32-bit fields. The check 'if (cls)' was unnecessary; it never became NULL, as it was the pointer to 'symval' plus the offset to the 'cls' field. Fixes: 26095a01d359 ("ACPI / scan: Add support for ACPI _CLS device matching") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-31kconfig: show sub-menu entries even if the prompt is hiddenMasahiro Yamada
Since commit f79dc03fe68c ("kconfig: refactor choice value calculation"), when EXPERT is disabled, nothing within the "if INPUT" ... "endif" block in drivers/input/Kconfig is displayed. This issue affects all command-line interfaces and GUI frontends. The prompt for INPUT is hidden when EXPERT is disabled. Previously, menu_is_visible() returned true in this case; however, it now returns false, resulting in all sub-menu entries being skipped. Here is a simplified test case illustrating the issue: config A bool "A" if X default y config B bool "B" depends on A When X is disabled, A becomes unconfigurable and is forced to y. B should be displayed, as its dependency is met. This commit restores the necessary code, so menu_is_visible() functions as it did previously. Fixes: f79dc03fe68c ("kconfig: refactor choice value calculation") Reported-by: Edmund Raile <edmund.raile@proton.me> Closes: https://lore.kernel.org/all/5fd0dfc7ff171aa74352e638c276069a5f2e888d.camel@proton.me/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-31kbuild: deb-pkg: add pkg.linux-upstream.nokerneldbg build profileMasahiro Yamada
The Debian kernel supports the pkg.linux.nokerneldbg build profile. The debug package tends to become huge, and you may not want to build it even when CONFIG_DEBUG_INFO is enabled. This commit introduces a similar profile for the upstream kernel. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-10-31kbuild: deb-pkg: add pkg.linux-upstream.nokernelheaders build profileMasahiro Yamada
Since commit f1d87664b82a ("kbuild: cross-compile linux-headers package when possible"), 'make bindeb-pkg' may attempt to cross-compile the linux-headers package, but it fails under certain circumstances. For example, when CONFIG_MODULE_SIG_FORMAT is enabled on Debian, the following command fails: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg [ snip ] Rebuilding host programs with aarch64-linux-gnu-gcc... HOSTCC debian/linux-headers-6.12.0-rc4/usr/src/linux-headers-6.12.0-rc4/scripts/kallsyms HOSTCC debian/linux-headers-6.12.0-rc4/usr/src/linux-headers-6.12.0-rc4/scripts/sorttable HOSTCC debian/linux-headers-6.12.0-rc4/usr/src/linux-headers-6.12.0-rc4/scripts/asn1_compiler HOSTCC debian/linux-headers-6.12.0-rc4/usr/src/linux-headers-6.12.0-rc4/scripts/sign-file In file included from /usr/include/openssl/opensslv.h:109, from debian/linux-headers-6.12.0-rc4/usr/src/linux-headers-6.12.0-rc4/scripts/sign-file.c:25: /usr/include/openssl/macros.h:14:10: fatal error: openssl/opensslconf.h: No such file or directory 14 | #include <openssl/opensslconf.h> | ^~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. This commit adds a new profile, pkg.linux-upstream.nokernelheaders, to guard the linux-headers package. There are two options to fix the above issue. Option 1: Set the pkg.linux-upstream.nokernelheaders build profile $ DEB_BUILD_PROFILES=pkg.linux-upstream.nokernelheaders \ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg This skips the building of the linux-headers package. Option 2: Install the necessary build dependencies If you want to cross-compile the linux-headers package, you need to install additional packages. For example, on Debian, the packages necessary for cross-compiling it to arm64 can be installed with the following commands: # dpkg --add-architecture arm64 # apt update # apt install gcc-aarch64-linux-gnu libssl-dev:arm64 Fixes: f1d87664b82a ("kbuild: cross-compile linux-headers package when possible") Reported-by: Ron Economos <re@w6rz.net> Closes: https://lore.kernel.org/all/b3d4f49e-7ddb-29ba-0967-689232329b53@w6rz.net/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Ron Economos <re@w6rz.net> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-10-31kbuild: rpm-pkg: disable kernel-devel package when cross-compilingMasahiro Yamada
Since commit f1d87664b82a ("kbuild: cross-compile linux-headers package when possible"), 'make binrpm-pkg' may attempt to cross-compile the kernel-devel package, but it fails under certain circumstances. For example, when CONFIG_MODULE_SIG_FORMAT is enabled on openSUSE Tumbleweed, the following command fails: $ make ARCH=arm64 CROSS_COMPILE=aarch64-suse-linux- binrpm-pkg [ snip ] Rebuilding host programs with aarch64-suse-linux-gcc... HOSTCC /home/masahiro/ref/linux/rpmbuild/BUILDROOT/kernel-6.12.0_rc4-1.aarch64/usr/src/kernels/6.12.0-rc4/scripts/kallsyms HOSTCC /home/masahiro/ref/linux/rpmbuild/BUILDROOT/kernel-6.12.0_rc4-1.aarch64/usr/src/kernels/6.12.0-rc4/scripts/sorttable HOSTCC /home/masahiro/ref/linux/rpmbuild/BUILDROOT/kernel-6.12.0_rc4-1.aarch64/usr/src/kernels/6.12.0-rc4/scripts/asn1_compiler HOSTCC /home/masahiro/ref/linux/rpmbuild/BUILDROOT/kernel-6.12.0_rc4-1.aarch64/usr/src/kernels/6.12.0-rc4/scripts/sign-file /home/masahiro/ref/linux/rpmbuild/BUILDROOT/kernel-6.12.0_rc4-1.aarch64/usr/src/kernels/6.12.0-rc4/scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory 25 | #include <openssl/opensslv.h> | ^~~~~~~~~~~~~~~~~~~~ compilation terminated. I believe this issue is less common on Fedora because the disto's cross- compilier cannot link user-space programs. Hence, CONFIG_CC_CAN_LINK is unset. On Fedora 40, the package information explains this limitation clearly: $ dnf info gcc-aarch64-linux-gnu [ snip ] Description : Cross-build GNU C compiler. : : Only building kernels is currently supported. Support for cross-building : user space programs is not currently provided as that would massively multiply : the number of packages. Anyway, cross-compiling RPM packages is somewhat challenging. This commit disables the kernel-devel package when cross-compiling because I did not come up with a better solution. Fixes: f1d87664b82a ("kbuild: cross-compile linux-headers package when possible") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
2024-10-31kbuild: Add generic hook for architectures to use before the final vmlinux linkNaveen N Rao
On powerpc, we would like to be able to make a pass on vmlinux.o and generate a new object file to be linked into vmlinux. Add a generic pass in Makefile.vmlinux that architectures can use for this purpose. Architectures need to select CONFIG_ARCH_WANTS_PRE_LINK_VMLINUX and must provide arch/<arch>/tools/Makefile with .arch.vmlinux.o target, which will be invoked prior to the final vmlinux link step. Acked-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Naveen N Rao <naveen@kernel.org> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/20241030070850.1361304-12-hbathini@linux.ibm.com
2024-10-28kbuild: rust: avoid errors with old `rustc`s without LLVM patch versionMiguel Ojeda
Some old versions of `rustc` did not report the LLVM version without the patch version, e.g.: $ rustc --version --verbose rustc 1.48.0 (7eac88abb 2020-11-16) binary: rustc commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4 commit-date: 2020-11-16 host: x86_64-unknown-linux-gnu release: 1.48.0 LLVM version: 11.0 Which would make the new `scripts/rustc-llvm-version.sh` fail and, in turn, the build: $ make LLVM=1 SYNC include/config/auto.conf.cmd ./scripts/rustc-llvm-version.sh: 13: arithmetic expression: expecting primary: "10000 * 10 + 100 * 0 + " init/Kconfig:83: syntax error init/Kconfig:83: invalid statement make[3]: *** [scripts/kconfig/Makefile:85: syncconfig] Error 1 make[2]: *** [Makefile:679: syncconfig] Error 2 make[1]: *** [/home/cam/linux/Makefile:780: include/config/auto.conf.cmd] Error 2 make: *** [Makefile:224: __sub-make] Error 2 Since we do not need to support such binaries, we can avoid adding logic for computing `rustc`'s LLVM version for those old binaries. Thus, instead, just make the match stricter. Other `rustc` binaries (even newer) did not report the LLVM version at all, but that was fine, since it would not match "LLVM", e.g.: $ rustc --version --verbose rustc 1.49.0 (e1884a8e3 2020-12-29) binary: rustc commit-hash: e1884a8e3c3e813aada8254edfa120e85bf5ffca commit-date: 2020-12-29 host: x86_64-unknown-linux-gnu release: 1.49.0 Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Gary Guo <gary@garyguo.net> Reported-by: Cameron MacPherson <cameron.macpherson@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219423 Fixes: af0121c2d303 ("kbuild: rust: add `CONFIG_RUSTC_LLVM_VERSION`") Tested-by: Cameron MacPherson <cameron.macpherson@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20241027145636.416030-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-24Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfAlexei Starovoitov
Cross-merge bpf fixes after downstream PR. No conflicts. Adjacent changes in: include/linux/bpf.h include/uapi/linux/bpf.h kernel/bpf/btf.c kernel/bpf/helpers.c kernel/bpf/syscall.c kernel/bpf/verifier.c kernel/trace/bpf_trace.c mm/slab_common.c tools/include/uapi/linux/bpf.h tools/testing/selftests/bpf/Makefile Link: https://lore.kernel.org/all/20241024215724.60017-1-daniel@iogearbox.net/ Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-10-23sumversion: Fix a memory leak in get_src_version()Elena Salomatkina
strsep() modifies its first argument - buf. An invalid pointer will be passed to the free() function. Make the pointer passed to free() match the return value of read_text_file(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9413e7640564 ("kbuild: split the second line of *.mod into *.usyms") Signed-off-by: Elena Salomatkina <esalomatkina@ispras.ru> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-21reiserfs: The last commitJan Kara
Deprecation period of reiserfs ends with the end of this year so it is time to remove it from the kernel. Acked-by: Darrick J. Wong <djwong@kernel.org> Acked-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Jan Kara <jack@suse.cz>
2024-10-19modules: Add missing entry for __ex_tableHelge Deller
The entry for __ex_table was missing, which may make __ex_table become 1- or 2-byte aligned in modules. Add the entry to ensure it gets 32-bit aligned. As per unaligned-memory-access [0] "unaligned memory accesses [...] will not work correctly on certain platforms and will cause performance problems on others", so fix this. Signed-off-by: Helge Deller <deller@gmx.de> [mcgrof: added unaligned-memory-access justification] Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/core-api/unaligned-memory-access.rst # [0] Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2024-10-19modules: Ensure 64-bit alignment on __ksymtab_* sectionsHelge Deller
On 64-bit architectures without CONFIG_HAVE_ARCH_PREL32_RELOCATIONS (e.g. ppc64, ppc64le, parisc, s390x,...) the __KSYM_REF() macro stores 64-bit pointers into the __ksymtab* sections. Make sure that those sections will be correctly aligned at module link time, otherwise unaligned memory accesses may happen at runtime. As per unaligned-memory-access [0] "unaligned memory accesses [...] will not work correctly on certain platforms and will cause performance problems on others", so fix this. The __kcrctab* sections store 32-bit entities, so use ALIGN(4) for those. Signed-off-by: Helge Deller <deller@gmx.de> [mcgrof: added unaligned-memory-access justification] Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/core-api/unaligned-memory-access.rst # [0] Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2024-10-17Revert "scripts/faddr2line: Check only two symbols when calculating symbol size"Carlos Llamas
This reverts commit c02904f05ff805d6c0631634d5751ebd338f75ec. Such commit assumed that only two symbols are relevant for the symbol size calculation. However, this can lead to an incorrect symbol size calculation when there are mapping symbols emitted by readelf. For instance, when feeding 'update_irq_load_avg+0x1c/0x1c4', faddr2line might need to process the following readelf lines: 784284: ffffffc0081cca30 428 FUNC GLOBAL DEFAULT 2 update_irq_load_avg 87319: ffffffc0081ccb0c 0 NOTYPE LOCAL DEFAULT 2 $x.62522 87321: ffffffc0081ccbdc 0 NOTYPE LOCAL DEFAULT 2 $x.62524 87323: ffffffc0081ccbe0 0 NOTYPE LOCAL DEFAULT 2 $x.62526 87325: ffffffc0081ccbe4 0 NOTYPE LOCAL DEFAULT 2 $x.62528 87327: ffffffc0081ccbe8 0 NOTYPE LOCAL DEFAULT 2 $x.62530 87329: ffffffc0081ccbec 0 NOTYPE LOCAL DEFAULT 2 $x.62532 87331: ffffffc0081ccbf0 0 NOTYPE LOCAL DEFAULT 2 $x.62534 87332: ffffffc0081ccbf4 0 NOTYPE LOCAL DEFAULT 2 $x.62535 783403: ffffffc0081ccbf4 424 FUNC GLOBAL DEFAULT 2 sched_pelt_multiplier The symbol size of 'update_irq_load_avg' should be calculated with the address of 'sched_pelt_multiplier', after skipping the mapping symbols seen in between. However, the offending commit cuts the list short and faddr2line incorrectly assumes 'update_irq_load_avg' is the last symbol in the section, resulting in: $ scripts/faddr2line vmlinux update_irq_load_avg+0x1c/0x1c4 skipping update_irq_load_avg address at 0xffffffc0081cca4c due to size mismatch (0x1c4 != 0x3ff9a59988) no match for update_irq_load_avg+0x1c/0x1c4 After reverting the commit the issue is resolved: $ scripts/faddr2line vmlinux update_irq_load_avg+0x1c/0x1c4 update_irq_load_avg+0x1c/0x1c4: cpu_of at kernel/sched/sched.h:1109 (inlined by) update_irq_load_avg at kernel/sched/pelt.c:481 Fixes: c02904f05ff8 ("scripts/faddr2line: Check only two symbols when calculating symbol size") Signed-off-by: Carlos Llamas <cmllamas@google.com> Acked-by: Will Deacon <will@kernel.org> Acked-by: Brian Johannesmeyer <bjohannesmeyer@gmail.com> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2024-10-17kernel-doc: allow object-like macros in ReST outputRandy Dunlap
output_function_rst() does not handle object-like macros. It presents a trailing "()" while output_function_man() handles these macros correctly. Update output_function_rst() to handle object-like macros. Don't show the "Parameters" heading if there are no parameters. For output_function_man(), don't show the "ARGUMENTS" heading if there are no parameters. I have tested this quite a bit with my ad hoc test files for both ReST and man format outputs. The generated output looks good. Fixes: cbb4d3e6510b ("scripts/kernel-doc: handle object-like macros") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Horia Geanta <horia.geanta@freescale.com> Tested-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241015181107.536894-1-rdunlap@infradead.org
2024-10-16checkpatch: Remove links to outdated documentationAnna-Maria Behnsen
checkpatch.pl checks for several things related to sleep and delay functions. In all warnings the outdated documentation is referenced. Also in checkpatch kernel documentation the outdated documentation is referenced. Replace the links to the outdated documentation with links to the function description. Note: Update of the outdated checkpatch checks is done in a second step. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/all/20241014-devel-anna-maria-b4-timers-flseep-v3-10-dc8b907cb62f@linutronix.de
2024-10-15kbuild: rust: remove the `alloc` crate and `GlobalAlloc`Danilo Krummrich
Now that we have our own `Allocator`, `Box` and `Vec` types we can remove Rust's `alloc` crate and the `new_uninit` unstable feature. Also remove `Kmalloc`'s `GlobalAlloc` implementation -- we can't remove this in a separate patch, since the `alloc` crate requires a `#[global_allocator]` to set, that implements `GlobalAlloc`. Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-29-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-14scripts/kernel-doc: Do not track section counter across processed filesChen-Yu Tsai
The section counter tracks how many sections of kernel-doc were added. The only real use of the counter value is to check if anything was actually supposed to be output and give a warning is nothing is available. The current logic of remembering the initial value and then resetting the value then when processing each file means that if a file has the same number of sections as the previously processed one, a warning is incorrectly given. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241008082905.4005524-1-wenst@chromium.org
2024-10-14scripts/kernel-doc: Fix build time warningsAndré Almeida
As stated at Documentation/kbuild/llvm.rst, to make usage of ccache one must set KBUILD_BUILD_TIMESTAMP=''. Setting this together with W=1 will trigger the following warning for every compiled file: date: invalid date ‘+%s’ This comes from kernel-doc script, that produces the following command when KBUILD_BUILD_TIMESTAMP is empty: date -d"" +%s That triggers the warning above. Add a space between the flag `-d` and the string argument to fix date command and remove the warning. Signed-off-by: André Almeida <andrealmeid@igalia.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241010225933.166436-1-andrealmeid@igalia.com
2024-10-13kbuild: rust: add `CONFIG_RUSTC_LLVM_VERSION`Gary Guo
Each version of Rust supports a range of LLVM versions. There are cases where we want to gate a config on the LLVM version instead of the Rust version. Normalized cfi integer tags are one example [1]. The invocation of rustc-version is being moved from init/Kconfig to scripts/Kconfig.include for consistency with cc-version. Link: https://lore.kernel.org/all/20240925-cfi-norm-kasan-fix-v1-1-0328985cdf33@google.com/ [1] Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20241011114040.3900487-1-gary@garyguo.net [ Added missing `-llvm` to the Usage documentation. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-10kbuild: fix issues with rustc-optionAlice Ryhl
Fix a few different compiler errors that cause rustc-option to give wrong results. If KBUILD_RUSTFLAGS or the flags being tested contain any -Z flags, then the error below is generated. The RUSTC_BOOTSTRAP environment variable is added to fix this error. error: the option `Z` is only accepted on the nightly compiler help: consider switching to a nightly toolchain: `rustup default nightly` note: selecting a toolchain with `+toolchain` arguments require a rustup proxy; see <https://rust-lang.github.io/rustup/concepts/index.html> note: for more information about Rust's stability policy, see <https://doc.rust-lang.org/book/appendix-07-nightly-rust.html#unstable-features> error: 1 nightly option were parsed Note that RUSTC_BOOTSTRAP is also defined in the top-level Makefile, but Make-exported variables are unfortunately *not* inherited. That said, this is changing as of commit 98da874c4303 ("[SV 10593] Export variables to $(shell ...) commands"), which is part of Make 4.4. The probe may also fail with the error message below. To fix it, the /dev/null argument is replaced with a file containing the crate attribute #![no_core]. The #![no_core] attribute ensures that rustc does not look for the standard library. It's not possible to instead supply a standard library (i.e. `core`) to rustc, as we need `rustc-option` before the Rust standard library is compiled. error[E0463]: can't find crate for `std` | = note: the `aarch64-unknown-none` target may not be installed = help: consider downloading the target with `rustup target add aarch64-unknown-none` = help: consider building the standard library from source with `cargo build -Zbuild-std` The -o and --out-dir parameters are altered to fix this warning: warning: ignoring --out-dir flag due to -o flag The --sysroot flag is provided as we would otherwise require it to be present in KBUILD_RUSTFLAGS. The --emit=obj flag is used to write the resulting object file to /dev/null instead of writing it to a file in $(TMPOUT). I verified that the Kconfig version of rustc-option doesn't have the same issues. Fixes: c42297438aee ("kbuild: rust: Define probing macros for rustc") Co-developed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20241009-rustc-option-bootstrap-v3-1-5fa0d520efba@google.com [ Reworded as discussed in the list. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-10kbuild: refactor cc-option-yn, cc-disable-warning, rust-option-yn macrosMasahiro Yamada
cc-option-yn and cc-disable-warning duplicate the compile command seen a few lines above. These can be defined based on cc-option. I also refactored rustc-option-yn in the same way, although there are currently no users of it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20241009102821.2675718-1-masahiroy@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-09const_structs.checkpatch: add ctl_tableThomas Weißschuh
Now that the sysctl core can handle "const struct ctl_table", make sure that new usages of the struct already enter the tree as const. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Joel Granados <joel.granados@kernel.org>
2024-10-08tracing: Remove definition of trace_*_rcuidle()Steven Rostedt
The trace_*_rcuidle() variant of a tracepoint was to handle places where a tracepoint was located but RCU was not "watching". All those locations have been removed, and RCU should be watching where all tracepoints are located. We can now remove the trace_*_rcuidle() variant. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Joel Fernandes <joel@joelfernandes.org> Link: https://lore.kernel.org/20241003181629.36209057@gandalf.local.home Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2024-10-07rust: enable arbitrary_self_types and remove `Receiver`Gary Guo
The term "receiver" means that a type can be used as the type of `self`, and thus enables method call syntax `foo.bar()` instead of `Foo::bar(foo)`. Stable Rust as of today (1.81) enables a limited selection of types (primitives and types in std, e.g. `Box` and `Arc`) to be used as receivers, while custom types cannot. We want the kernel `Arc` type to have the same functionality as the Rust std `Arc`, so we use the `Receiver` trait (gated behind `receiver_trait` unstable feature) to gain the functionality. The `arbitrary_self_types` RFC [1] (tracking issue [2]) is accepted and it will allow all types that implement a new `Receiver` trait (different from today's unstable trait) to be used as receivers. This trait will be automatically implemented for all `Deref` types, which include our `Arc` type, so we no longer have to opt-in to be used as receiver. To prepare us for the change, remove the `Receiver` implementation and the associated feature. To still allow `Arc` and others to be used as method receivers, turn on `arbitrary_self_types` feature instead. This feature gate is introduced in 1.23.0. It used to enable both `Deref` types and raw pointer types to be used as receivers, but the latter is now split into a different feature gate in Rust 1.83 nightly. We do not need receivers on raw pointers so this change would not affect us and usage of `arbitrary_self_types` feature would work for all Rust versions that we support (>=1.78). Cc: Adrian Taylor <ade@hohum.me.uk> Link: https://github.com/rust-lang/rfcs/pull/3519 [1] Link: https://github.com/rust-lang/rust/issues/44874 [2] Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240915132734.1653004-1-gary@garyguo.net Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-07rust: start using the `#[expect(...)]` attributeMiguel Ojeda
In Rust, it is possible to `allow` particular warnings (diagnostics, lints) locally, making the compiler ignore instances of a given warning within a given function, module, block, etc. It is similar to `#pragma GCC diagnostic push` + `ignored` + `pop` in C: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-function" static void f(void) {} #pragma GCC diagnostic pop But way less verbose: #[allow(dead_code)] fn f() {} By that virtue, it makes it possible to comfortably enable more diagnostics by default (i.e. outside `W=` levels) that may have some false positives but that are otherwise quite useful to keep enabled to catch potential mistakes. The `#[expect(...)]` attribute [1] takes this further, and makes the compiler warn if the diagnostic was _not_ produced. For instance, the following will ensure that, when `f()` is called somewhere, we will have to remove the attribute: #[expect(dead_code)] fn f() {} If we do not, we get a warning from the compiler: warning: this lint expectation is unfulfilled --> x.rs:3:10 | 3 | #[expect(dead_code)] | ^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default This means that `expect`s do not get forgotten when they are not needed. See the next commit for more details, nuances on its usage and documentation on the feature. The attribute requires the `lint_reasons` [2] unstable feature, but it is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has already been useful to clean things up in this patch series, finding cases where the `allow`s should not have been there. Thus, enable `lint_reasons` and convert some of our `allow`s to `expect`s where possible. This feature was also an example of the ongoing collaboration between Rust and the kernel -- we tested it in the kernel early on and found an issue that was quickly resolved [3]. Cc: Fridtjof Stoldt <xfrednet@gmail.com> Cc: Urgau <urgau@numericable.fr> Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1] Link: https://github.com/rust-lang/rust/issues/54503 [2] Link: https://github.com/rust-lang/rust/issues/114557 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-07kbuild: deb-pkg: Remove blank first line from maint scriptsAaron Thompson
The blank line causes execve() to fail: # strace ./postinst execve("./postinst", ...) = -1 ENOEXEC (Exec format error) strace: exec: Exec format error +++ exited with 1 +++ However running the scripts via shell does work (at least with bash) because the shell attempts to execute the file as a shell script when execve() fails. Fixes: b611daae5efc ("kbuild: deb-pkg: split image and debug objects staging out into functions") Signed-off-by: Aaron Thompson <dev@aaront.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-07scripts: import more list macrosSami Tolvanen
Import list_is_first, list_is_last, list_replace, and list_replace_init. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-03bpf: Allow specifying bpf_fastcall attribute for BPF helpersEduard Zingerman
Allow a new optional 'Attributes' section to be specified for helper functions description, e.g.: * u32 bpf_get_smp_processor_id(void) * ... * Return * ... * Attributes * __bpf_fastcall * Generated header for the example above: #ifndef __bpf_fastcall #if __has_attribute(__bpf_fastcall) #define __bpf_fastcall __attribute__((bpf_fastcall)) #else #define __bpf_fastcall #endif #endif ... __bpf_fastcall static __u32 (* const bpf_get_smp_processor_id)(void) = (void *) 8; The following rules apply: - when present, section must follow 'Return' section; - attribute names are specified on the line following 'Attribute' keyword; - attribute names are separated by spaces; - section ends with an "empty" line (" *\n"). Valid attribute names are recorded in the ATTRS map. ATTRS maps shortcut attribute name to correct C syntax. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240916091712.2929279-2-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-10-03selinux: move genheaders to security/selinux/Masahiro Yamada
This tool is only used in security/selinux/Makefile. Move it to security/selinux/ so that 'make clean' can clean it up. Please note 'make clean' does not clean scripts/ because tools under scripts/ are often used for external module builds. Obviously, genheaders is not the case here. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-10-03selinux: do not include <linux/*.h> headers from host programsMasahiro Yamada
The header, security/selinux/include/classmap.h, is included not only from kernel space but also from host programs. It includes <linux/capability.h> and <linux/socket.h>, which pull in more <linux/*.h> headers. This makes the host programs less portable, specifically causing build errors on macOS. Those headers are included for the following purposes: - <linux/capability.h> for checking CAP_LAST_CAP - <linux/socket.h> for checking PF_MAX These checks can be guarded by __KERNEL__ so they are skipped when building host programs. Testing them when building the kernel should be sufficient. The header, security/selinux/include/initial_sid_to_string.h, includes <linux/stddef.h> for the NULL definition, but this is not portable either. Instead, <stddef.h> should be included for host programs. Reported-by: Daniel Gomez <da.gomez@samsung.com> Closes: https://lore.kernel.org/lkml/20240807-macos-build-support-v1-6-4cd1ded85694@samsung.com/ Closes: https://lore.kernel.org/lkml/20240807-macos-build-support-v1-7-4cd1ded85694@samsung.com/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-10-02kconfig: qconf: fix buffer overflow in debug linksMasahiro Yamada
If you enable "Option -> Show Debug Info" and click a link, the program terminates with the following error: *** buffer overflow detected ***: terminated The buffer overflow is caused by the following line: strcat(data, "$"); The buffer needs one more byte to accommodate the additional character. Fixes: c4f7398bee9c ("kconfig: qconf: make debug links work again") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-01kconfig: qconf: move conf_read() before drawing tree painMasahiro Yamada
The constructor of ConfigMainWindow() calls show*View(), which needs to calculate symbol values. conf_read() must be called before that. Fixes: 060e05c3b422 ("kconfig: qconf: remove initial call to conf_changed()") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-01kconfig: clear expr::val_is_valid when allocatedMasahiro Yamada
Since commit 95573cac25c6 ("kconfig: cache expression values"), xconfig emits a lot of false-positive "unmet direct dependencies" warnings. While conf_read() clears val_is_valid flags, 'make xconfig' calculates symbol values even before the conf_read() call. This is another issue that should be addressed separately, but it has revealed that the val_is_valid field is not initialized. Fixes: 95573cac25c6 ("kconfig: cache expression values") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-30kconfig: fix infinite loop in sym_calc_choice()Masahiro Yamada
Since commit f79dc03fe68c ("kconfig: refactor choice value calculation"), Kconfig for ARCH=powerpc may result in an infinite loop. This occurs because there are two entries for POWERPC64_CPU in a choice block. If the same symbol appears twice in a choice block, the ->choice_link node is added twice to ->choice_members, resulting a corrupted linked list. A simple test case is: choice prompt "choice" config A bool "A" config B bool "B 1" config B bool "B 2" endchoice Running 'make defconfig' results in an infinite loop. One solution is to replace the current two entries: config POWERPC64_CPU bool "Generic (POWER5 and PowerPC 970 and above)" depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN select PPC_64S_HASH_MMU config POWERPC64_CPU bool "Generic (POWER8 and above)" depends on PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN select ARCH_HAS_FAST_MULTIPLIER select PPC_64S_HASH_MMU select PPC_HAS_LBARX_LHARX with the following single entry: config POWERPC64_CPU bool "Generic 64 bit powerpc" depends on PPC_BOOK3S_64 select ARCH_HAS_FAST_MULTIPLIER if CPU_LITTLE_ENDIAN select PPC_64S_HASH_MMU select PPC_HAS_LBARX_LHARX if CPU_LITTLE_ENDIAN In my opinion, the latter looks cleaner, but PowerPC maintainers may prefer to display different prompts depending on CPU_LITTLE_ENDIAN. For now, this commit fixes the issue in Kconfig, restoring the original behavior. I will reconsider whether such a use case is worth supporting. Fixes: f79dc03fe68c ("kconfig: refactor choice value calculation") Reported-by: Marco Bonelli <marco@mebeim.net> Closes: https://lore.kernel.org/all/1763151587.3581913.1727224126288@privateemail.com/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-30kbuild: move non-boot built-in DTBs to .rodata sectionMasahiro Yamada
Commit aab94339cd85 ("of: Add support for linking device tree blobs into vmlinux") introduced a mechanism to embed DTBs into vmlinux. Initially, it was used for wrapping boot DTBs in arch/*/boot/dts/, but it is now reused for more generic purposes, such as testing. Built-in DTBs are discarded because KERNEL_DTB() is part of INIT_DATA, as defined in include/asm-generic/vmlinux.lds.h. This has not been an issue so far because OF unittests are triggered during boot, as defined by late_initcall(of_unittest). However, the recent clk KUnit test additions have caused problems because KUnit can execute test suites after boot. For example: # echo > /sys/kernel/debug/kunit/clk_register_clk_parent_data_device/run This command triggers a stack trace because built-in DTBs have already been freed. While it is possible to move such test suites from kunit_test_suites to kunit_test_init_section_suites, it would be preferable to avoid usage limitations. This commit moves non-boot built-in DTBs to the .rodata section. Since these generic DTBs are looked up by name, they do not need to be placed in the special .dtb.init.rodata section. Boot DTBs should remain in .dtb.init.rodata because the arch boot code generally does not know the DT name, thus it uses the __dtb_start symbol to locate it. This separation also ensures that the __dtb_start symbol references the boot DTB. Currently, the .dtb.init.rodata is a mixture of both boot and non-boot DTBs. The __dtb_start symbol must be followed by the boot DTB, but we currently rely on the link order (i.e., the order in Makefiles), which is very fragile. The implementation is kind of cheesy; the section is .dtb.init.rodata when $(obj) starts with arch/$(SRCARCH)/boot/dts, and .rodata section otherwise. This will be refactored later. Fixes: 5c9dd72d8385 ("of: Add a KUnit test for overlays and test managed APIs") Fixes: 5776526beb95 ("clk: Add KUnit tests for clk fixed rate basic type") Fixes: 274aff8711b2 ("clk: Add KUnit tests for clks registered with struct clk_parent_data") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-28Reduce Coccinelle choices in string_choices.cocciJulia Lawall
The isomorphism neg_if_exp negates the test of a ?: conditional, making it unnecessary to have an explicit case for a negated test with the branches inverted. At the same time, we can disable neg_if_exp in cases where a different API function may be more suitable for a negated test. Finally, in the non-patch cases, E matches an expression with parentheses around it, so there is no need to mention () explicitly in the pattern. The () are still needed in the patch cases, because we want to drop them, if they are present. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2024-09-28coccinelle: Remove unnecessary parentheses for only one possible change.Hongbo Li
The parentheses are only needed if there is a disjunction, ie a set of possible changes. If there is only one pattern, we can remove these parentheses. Just like the format: - x + y not: ( - x + y ) Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2024-09-28coccinelle: Add rules to find str_yes_no() replacementsHongbo Li
As other rules done, we add rules for str_yes_no() to check the relative opportunities. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2024-09-28coccinelle: Add rules to find str_on_off() replacementsHongbo Li
As other rules done, we add rules for str_on_off() to check the relative opportunities. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2024-09-28coccinelle: Add rules to find str_write_read() replacementsHongbo Li
As other rules done, we add rules for str_write_read() to check the relative opportunities. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2024-09-28coccinelle: Add rules to find str_read_write() replacementsHongbo Li
As other rules done, we add rules for str_read_write() to check the relative opportunities. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2024-09-28coccinelle: Add rules to find str_enable{d}_disable{d}() replacementsHongbo Li
As other rules done, we add rules for str_enable{d}_ disable{d}() to check the relative opportunities. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2024-09-28coccinelle: Add rules to find str_lo{w}_hi{gh}() replacementsHongbo Li
As other rules done, we add rules for str_lo{w}_hi{gh}() to check the relative opportunities. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2024-09-28coccinelle: Add rules to find str_hi{gh}_lo{w}() replacementsHongbo Li
As other rules done, we add rules for str_hi{gh}_lo{w}() to check the relative opportunities. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
generated by cgit (git 2.34.1) at 2025-07-16 00:49:14 +0000