kernel/linux.git/Documentation/process/submit-checklist.rst, branch v6.19.11

docs/.../submit-checklist: Use Documentation/admin-guide/abi.rst for cross-ref of README

2025-03-12T22:41:56+00:00

Commit fb12098d8ee4 ("docs: submit-checklist: Allow creating cross-references for ABI README") assumes that the path of "Documentation/ABI/README" would be converted to a cross-ref to the README. However, as the README is included by the "kernel-abi" directive at Documentation/admin-guide/abi.rst, the expected conversion does not happen. Instead, use the path where the "kernel-abi" directive exists for the conversion to work. Restore the original path of README in inline-literal form as an additional note for readers of the .rst file. Apply the same changes for translations. Signed-off-by: Akira Yokosawa Fixes: fb12098d8ee4 ("docs: submit-checklist: Allow creating cross-references for ABI README") Fixes: eb0c714120ba ("docs: translations: Allow creating cross-references for ABI README") Cc: Mauro Carvalho Chehab Cc: Alex Shi Cc: Yanteng Si Cc: Dongliang Mu Cc: Hu Haowen <2023002089@link.tyut.edu.cn> Cc: Federico Vaga Cc: Carlos Bilbao Cc: Avadhut Naik Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20250304075734.56660-1-akiyks@gmail.com

docs: submit-checklist: Allow creating cross-references for ABI README

2025-02-18T20:42:46+00:00

Now that Documentation/ABI is processed by automarkup, let it generate cross-references for the ABI README file. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/76e60ee8717551f3d15d7c92b9c93bbf2ca8cff3.1739254867.git.mchehab+huawei@kernel.org

docs: submit-checklist: Expand on build tests against different word sizes

2025-02-10T18:00:44+00:00

Existing sentence on cross-compilation that mentions ppc64 does not make much sense in today's perspective. Expand it for the benefits of testing against architectures of different word sizes and endianness. Signed-off-by: Akira Yokosawa Reviewed-by: Randy Dunlap Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/05c0b99c-c2e9-4702-90fd-8a4127586424@gmail.com

docs: submit-checklist: use subheadings

2024-03-03T15:41:33+00:00

During review (see Link), Jani Nikula suggested to use proper subheadings instead of using italics to indicate the different new top-level categories in the checklist. Further the top heading should follow the common scheme. Use subheadings. Adjust to common heading adornment. Link: https://lore.kernel.org/linux-doc/87o7c3mlwb.fsf@intel.com/ Signed-off-by: Lukas Bulwahn Reviewed-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20240229030743.9125-3-lukas.bulwahn@gmail.com>

docs: submit-checklist: structure by category

2024-03-03T15:41:33+00:00

While going through the submit checklist, the list order seemed rather random, probably just by historical coincidences of always adding yet the next point someone thought of at the end of the list. Structure and order them by the category of such activity, reviewing, documenting, checking with tools, building and testing. As the diff of the reordering is large: Review code now includes previous points 1, 5 and 22. Review Kconfig includes previous 6, 7 and 8. Documenting includes previous 11, 15, 16, 17, 18 and 23. Checking with tools includes previous 5, 9 and 10. Building includes previous 2, 3, 20 and 24. Testing includes previous 12, 13, 14, 19 and 21. Previous point 4 (compile for ppc64) was merged into point 3 (build for many architectures), as it was just a further note to cross-compiling. Previous point 5 was split into one in review and one in checking to have every previous point in the right category. Point 11 was shortened, as building documentation is mentioned already in Build your code, 1d. A note that was presented visually much too aggressive in the HTML view was turned into a simple "Note that..." sentence in the enumeration. The recommendation to test with the -mm patchset (previous 21, now testing, point 5) was updated to the current state of affairs to test with a recent tag of linux-next. Note that the previous first point still remains the first list even after reordering. Randy confirmed that it was important to Stephen Rothwell to keep 'include what you use' to be the first in the list. While at it, replace the reference to the obsolete CONFIG_DEBUG_SLAB with CONFIG_SLUB_DEBUG. Reviewed-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Lukas Bulwahn Signed-off-by: Jonathan Corbet Message-ID: <20240229030743.9125-2-lukas.bulwahn@gmail.com>

doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags from command line

2021-02-22T20:59:10+00:00

You should use KCFLAGS to pass additional compiler flags from the command line. Using EXTRA_CFLAGS is wrong. EXTRA_CFLAGS is supposed to specify flags applied only to the current Makefile (and now deprecated in favor of ccflags-y). It is still used in arch/mips/kvm/Makefile (and possibly in external modules too). Passing EXTRA_CFLAGS from the command line overwrites it and breaks the build. I also fixed drivers/gpu/drm/tilcdc/Makefile because commit 816175dd1fd7 ("drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in EXTRA_CFLAGS") was based on the same misunderstanding. Signed-off-by: Masahiro Yamada Reviewed-by: Alex Shi Acked-by: Federico Vaga Link: https://lore.kernel.org/r/20210221152524.197693-1-masahiroy@kernel.org Signed-off-by: Jonathan Corbet

docs: Remove make headers_check from checklist

2021-01-18T20:25:52+00:00

Remove the make headers_check step from submit-checklist.rst as this is no longer functional. Signed-off-by: Milan Lakhani Link: https://lore.kernel.org/r/1610458861-2832-1-git-send-email-milan.lakhani@codethink.co.uk Signed-off-by: Jonathan Corbet

Documentation: process: Correct numbering

2020-12-21T16:47:00+00:00

Renumber the steps in submit-checklist.rst as some numbers were skipped. Signed-off-by: Milan Lakhani Link: https://lore.kernel.org/r/1608064956-5512-1-git-send-email-milan.lakhani@codethink.co.uk Signed-off-by: Jonathan Corbet

Merge tag 'kbuild-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

2020-10-22T20:13:57+00:00

Pull Kbuild updates from Masahiro Yamada: - Support 'make compile_commands.json' to generate the compilation database more easily, avoiding stale entries - Support 'make clang-analyzer' and 'make clang-tidy' for static checks using clang-tidy - Preprocess scripts/modules.lds.S to allow CONFIG options in the module linker script - Drop cc-option tests from compiler flags supported by our minimal GCC/Clang versions - Use always 12-digits commit hash for CONFIG_LOCALVERSION_AUTO=y - Use sha1 build id for both BFD linker and LLD - Improve deb-pkg for reproducible builds and rootless builds - Remove stale, useless scripts/namespace.pl - Turn -Wreturn-type warning into error - Fix build error of deb-pkg when CONFIG_MODULES=n - Replace 'hostname' command with more portable 'uname -n' - Various Makefile cleanups * tag 'kbuild-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (34 commits) kbuild: Use uname for LINUX_COMPILE_HOST detection kbuild: Only add -fno-var-tracking-assignments for old GCC versions kbuild: remove leftover comment for filechk utility treewide: remove DISABLE_LTO kbuild: deb-pkg: clean up package name variables kbuild: deb-pkg: do not build linux-headers package if CONFIG_MODULES=n kbuild: enforce -Werror=return-type scripts: remove namespace.pl builddeb: Add support for all required debian/rules targets builddeb: Enable rootless builds builddeb: Pass -n to gzip for reproducible packages kbuild: split the build log of kallsyms kbuild: explicitly specify the build id style scripts/setlocalversion: make git describe output more reliable kbuild: remove cc-option test of -Werror=date-time kbuild: remove cc-option test of -fno-stack-check kbuild: remove cc-option test of -fno-strict-overflow kbuild: move CFLAGS_{KASAN,UBSAN,KCSAN} exports to relevant Makefiles kbuild: remove redundant CONFIG_KASAN check from scripts/Makefile.kasan kbuild: do not create built-in objects for external module builds ...

scripts: remove namespace.pl

2020-10-11T16:58:53+00:00

namespace.pl is intended to help locate symbols which are defined but are not used externally. The goal is to avoid bloat of the namespace in the resulting kernel image. The script relies on object data, and only finds unused symbols for the configuration used to generate that object data. This results in a lot of false positive warnings such as symbols only used by a single architecture, or symbols which are used externally only under certain configurations. Running namespace.pl using allyesconfig, allmodconfig, and x86_64_defconfig yields the following results: * allmodconfig * 11122 unique symbol names with no external reference * 1194 symbols listed as multiply defined * 214 symbols it can't resolve * allyesconfig * 10997 unique symbol names with no external reference * 1194 symbols listed as multiply defined * 214 symbols it can't resolve * x86_64_defconfig * 5757 unique symbol names with no external reference * 528 symbols listed as multiply defined * 154 symbols it can't resolve The script also has no way to easily limit the scope of the checks to a given subset of the kernel, such as only checking for symbols defined within a module or subsystem. Discussion on public mailing lists seems to indicate that many view the tool output as suspect or not very useful (see discussions at [1] and [2] for further context). As described by Masahiro Yamada at [2], namespace.pl provides 3 types of checks: listing multiply defined symbols, resolving external symbols, and warnings about symbols with no reference. The first category of issues is easily caught by the linker as any set of multiply defined symbols should fail to link. The second category of issues is also caught by linking, as undefined symbols would cause issues. Even with modules, these types of issues where a module relies on an external symbol are caught by modpost. The remaining category of issues reported is the list of symbols with no external reference, and is the primary motivation of this script. However, it ought to be clear from the above examples that the output is difficult to sort through. Even allyesconfig has ~10000 entries. The current submit-checklist indicates that patches ought to go through namespacecheck and fix any new issues arising. But that itself presents problems. As described at [1], many cases of reports are due to configuration where a function is used externally by some configuration settings. Prominent maintainers appear to dislike changes modify code such that symbols become static based on CONFIG_* flags ([3], and [4]) One possible solution is to adjust the advice and indicate that we only care about the output of namespacecheck on allyesconfig or allmodconfig builds... However, given the discussion at [2], I suspect that few people are actively using this tool. It doesn't have a maintainer in the MAINTAINERS flie, and it produces so many warnings for unused symbols that it is difficult to use effectively. Thus, I propose we simply remove it. [1] https://lore.kernel.org/netdev/20200708164812.384ae8ea@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/ [2] https://lore.kernel.org/lkml/20190129204319.15238-1-jacob.e.keller@intel.com/ [3] https://lore.kernel.org/netdev/20190828.154744.2058157956381129672.davem@davemloft.net/ [4] https://lore.kernel.org/netdev/20190827210928.576c5fef@cakuba.netronome.com/ Signed-off-by: Jacob Keller Acked-by: Randy Dunlap Acked-by: Jakub Kicinski Signed-off-by: Masahiro Yamada