user/sven/linux.git/usr/include, branch v6.7.6

arch: Remove Itanium (IA-64) architecture

2023-09-11T08:13:17Z

The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS based. The use of Linux on Itanium appears to be limited to enthusiasts that occasionally boot a fresh Linux kernel to see whether things are still working as intended, and perhaps to churn out some distro packages that are rarely used in practice. None of the original companies behind Itanium still produce or support any hardware or software for the architecture, and it is listed as 'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers that contributed on behalf of those companies (nor anyone else, for that matter) have been willing to support or maintain the architecture upstream or even be responsible for applying the odd fix. The Intel firmware team removed all IA-64 support from the Tianocore/EDK2 reference implementation of EFI in 2018. (Itanium is the original architecture for which EFI was developed, and the way Linux supports it deviates significantly from other architectures.) Some distros, such as Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have dropped support years ago. While the argument is being made [1] that there is a 'for the common good' angle to being able to build and run existing projects such as the Grid Community Toolkit [2] on Itanium for interoperability testing, the fact remains that none of those projects are known to be deployed on Linux/ia64, and very few people actually have access to such a system in the first place. Even if there were ways imaginable in which Linux/ia64 could be put to good use today, what matters is whether anyone is actually doing that, and this does not appear to be the case. There are no emulators widely available, and so boot testing Itanium is generally infeasible for ordinary contributors. GCC still supports IA-64 but its compile farm [3] no longer has any IA-64 machines. GLIBC would like to get rid of IA-64 [4] too because it would permit some overdue code cleanups. In summary, the benefits to the ecosystem of having IA-64 be part of it are mostly theoretical, whereas the maintenance overhead of keeping it supported is real. So let's rip off the band aid, and remove the IA-64 arch code entirely. This follows the timeline proposed by the Debian/ia64 maintainer [5], which removes support in a controlled manner, leaving IA-64 in a known good state in the most recent LTS release. Other projects will follow once the kernel support is removed. [0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/ [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/ [2] https://gridcf.org/gct-docs/latest/index.html [3] https://cfarm.tetaneutral.net/machines/list/ [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/ [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/ Acked-by: Tony Luck Signed-off-by: Ard Biesheuvel

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

2022-05-26T19:09:50Z

Pull Kbuild updates from Masahiro Yamada: - Add HOSTPKG_CONFIG env variable to allow users to override pkg-config - Support W=e as a shorthand for KCFLAGS=-Werror - Fix CONFIG_IKHEADERS build to support toybox cpio - Add scripts/dummy-tools/pahole to ease distro packagers' life - Suppress false-positive warnings from checksyscalls.sh for W=2 build - Factor out the common code of arch/*/boot/install.sh into scripts/install.sh - Support 'kernel-install' tool in scripts/prune-kernel - Refactor module-versioning to link the symbol versions at the final link of vmlinux and modules - Remove CONFIG_MODULE_REL_CRCS because module-versioning now works in an arch-agnostic way - Refactor modpost, Makefiles * tag 'kbuild-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (56 commits) genksyms: adjust the output format to modpost kbuild: stop merging *.symversions kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS modpost: extract symbol versions from *.cmd files modpost: add sym_find_with_module() helper modpost: change the license of EXPORT_SYMBOL to bool type modpost: remove left-over cross_compile declaration kbuild: record symbol versions in *.cmd files kbuild: generate a list of objects in vmlinux modpost: move *.mod.c generation to write_mod_c_files() modpost: merge add_{intree_flag,retpoline,staging_flag} to add_header scripts/prune-kernel: Use kernel-install if available kbuild: factor out the common installation code into scripts/install.sh modpost: split new_symbol() to symbol allocation and hash table addition modpost: make sym_add_exported() always allocate a new symbol modpost: make multiple export error modpost: dump Module.symvers in the same order of modules.order modpost: traverse the namespace_list in order modpost: use doubly linked list for dump_lists modpost: traverse unresolved symbols in order ...

sparc: add asm/stat.h to UAPI compile-test coverage

2022-05-13T08:56:10Z

asm/stat.h is currently excluded from the UAPI compile-test for ARCH=sparc because of the errors like follows: In file included from : ./usr/include/asm/stat.h:11:2: error: unknown type name 'ino_t' 11 | ino_t st_ino; | ^~~~~ HDRTEST usr/include/asm/param.h ./usr/include/asm/stat.h:12:2: error: unknown type name 'mode_t' 12 | mode_t st_mode; | ^~~~~~ ./usr/include/asm/stat.h:14:2: error: unknown type name 'uid_t' 14 | uid_t st_uid; | ^~~~~ ./usr/include/asm/stat.h:15:2: error: unknown type name 'gid_t' 15 | gid_t st_gid; | ^~~~~ The errors can be fixed by prefixing the types with __kernel_. Then, remove the no-header-test entry from user/include/Makefile. Signed-off-by: Masahiro Yamada Signed-off-by: Arnd Bergmann Reviewed-by: Christoph Hellwig

powerpc: add asm/stat.h to UAPI compile-test coverage

2022-05-13T08:56:10Z

asm/stat.h is currently excluded from the UAPI compile-test for ARCH=powerpc because of the errors like follows: HDRTEST usr/include/asm/stat.h In file included from :32: ./usr/include/asm/stat.h:32:2: error: unknown type name 'ino_t' 32 | ino_t st_ino; | ^~~~~ ./usr/include/asm/stat.h:35:2: error: unknown type name 'mode_t' 35 | mode_t st_mode; | ^~~~~~ ./usr/include/asm/stat.h:40:2: error: unknown type name 'uid_t' 40 | uid_t st_uid; | ^~~~~ ./usr/include/asm/stat.h:41:2: error: unknown type name 'gid_t' 41 | gid_t st_gid; | ^~~~~ The errors can be fixed by prefixing the types with __kernel_. Then, remove the no-header-test entry from user/include/Makefile. Signed-off-by: Masahiro Yamada Signed-off-by: Arnd Bergmann Reviewed-by: Christoph Hellwig

mips: add asm/stat.h to UAPI compile-test coverage

2022-05-13T08:56:10Z

asm/stat.h is currently excluded from the UAPI compile-test for ARCH=mips because of the errors like follows: HDRTEST usr/include/asm/stat.h In file included from :32: ./usr/include/asm/stat.h:22:2: error: unknown type name 'ino_t' 22 | ino_t st_ino; | ^~~~~ ./usr/include/asm/stat.h:23:2: error: unknown type name 'mode_t' 23 | mode_t st_mode; | ^~~~~~ ./usr/include/asm/stat.h:25:2: error: unknown type name 'uid_t' 25 | uid_t st_uid; | ^~~~~ ./usr/include/asm/stat.h:26:2: error: unknown type name 'gid_t' 26 | gid_t st_gid; | ^~~~~ ./usr/include/asm/stat.h:58:2: error: unknown type name 'mode_t' 58 | mode_t st_mode; | ^~~~~~ ./usr/include/asm/stat.h:61:2: error: unknown type name 'uid_t' 61 | uid_t st_uid; | ^~~~~ ./usr/include/asm/stat.h:62:2: error: unknown type name 'gid_t' 62 | gid_t st_gid; | ^~~~~ The errors can be fixed by prefixing the types with __kernel_. Then, remove the no-header-test entry from user/include/Makefile. Signed-off-by: Masahiro Yamada Signed-off-by: Arnd Bergmann Reviewed-by: Christoph Hellwig

riscv: add linux/bpf_perf_event.h to UAPI compile-test coverage

2022-05-13T08:56:10Z

I can compile this for ARCH=riscv with CONFIG_UAPI_HEADER_TEST=y. Signed-off-by: Masahiro Yamada Signed-off-by: Arnd Bergmann Reviewed-by: Christoph Hellwig

kbuild: prevent exported headers from including ,

2022-05-13T08:56:10Z

Some UAPI headers included , like this: #ifndef __KERNEL__ #include #endif As it turned out, they just included it for no good reason. After some fixes, now I can compile-test UAPI headers (CONFIG_UAPI_HEADER_TEST=y) without including from the system header search paths. To avoid somebody getting it back again, this commit adds the dummy header, usr/dummy-include/stdlib.h I added $(srctree)/usr/dummy-include to the header search paths. Because it is searched before the system directories, if someone tries to include , they will see the error message. While I am here, I also replaced $(objtree)/usr/include with $(obj), but it has no functional change. If we can make kernel headers self-contained (that is, none of exported kernel headers includes system headers), we will be able to add the -nostdinc flag, but that is much far from where we stand now. As a realistic solution, we can ban header inclusion individually by putting a dummy header into usr/dummy-include/. Currently, no header include . I put it as well before somebody attempts to use it. Signed-off-by: Masahiro Yamada Signed-off-by: Arnd Bergmann Reviewed-by: Greg Kroah-Hartman

kbuild: uapi: use -fsyntax-only rather than -S

2022-04-05T08:03:31Z

The UAPI header tests are checking that the generated headers do not have syntax errors. There's no need to run the rest of the compilation pipeline after semantic analysis has run. Replace -S -o /dev/null with -fsyntax-only. Signed-off-by: Nick Desaulniers Signed-off-by: Masahiro Yamada

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

2022-03-31T18:59:03Z

Pull Kbuild updates from Masahiro Yamada: - Add new environment variables, USERCFLAGS and USERLDFLAGS to allow additional flags to be passed to user-space programs. - Fix missing fflush() bugs in Kconfig and fixdep - Fix a minor bug in the comment format of the .config file - Make kallsyms ignore llvm's local labels, .L* - Fix UAPI compile-test for cross-compiling with Clang - Extend the LLVM= syntax to support LLVM= form for using a particular version of LLVm, and LLVM= form for using custom LLVM in a particular directory path. - Clean up Makefiles * tag 'kbuild-v5.18-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: Make $(LLVM) more flexible kbuild: add --target to correctly cross-compile UAPI headers with Clang fixdep: use fflush() and ferror() to ensure successful write to files arch: syscalls: simplify uapi/kapi directory creation usr/include: replace extra-y with always-y certs: simplify empty certs creation in certs/Makefile certs: include certs/signing_key.x509 unconditionally kallsyms: ignore all local labels prefixed by '.L' kconfig: fix missing '# end of' for empty menu kconfig: add fflush() before ferror() check kbuild: replace $(if A,A,B) with $(or A,B) kbuild: Add environment variables for userprogs flags kbuild: unify cmd_copy and cmd_shipped

kbuild: add --target to correctly cross-compile UAPI headers with Clang

2022-03-31T03:03:46Z

When you compile-test UAPI headers (CONFIG_UAPI_HEADER_TEST=y) with Clang, they are currently compiled for the host target (likely x86_64) regardless of the given ARCH=. In fact, some exported headers include libc headers. For example, include/uapi/linux/agpgart.h includes after being exported. The header search paths should match to the target we are compiling them for. Pick up the --target triple from KBUILD_CFLAGS in the same ways as commit 7f58b487e9ff ("kbuild: make Clang build userprogs for target architecture"). Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Reviewed-by: Nick Desaulniers