linux.git/usr/include, branch v6.12.80

kbuild: uapi: Strip comments before size type check

2025-11-13T20:34:35+00:00

[ Upstream commit 66128f4287b04aef4d4db9bf5035985ab51487d5 ]

On m68k, check_sizetypes in headers_check reports:

    ./usr/include/asm/bootinfo-amiga.h:17: found __[us]{8,16,32,64} type without #include 

This header file does not use any of the Linux-specific integer types,
but merely refers to them from comments, so this is a false positive.
As of commit c3a9d74ee413bdb3 ("kbuild: uapi: upgrade check_sizetypes()
warning to error"), this check was promoted to an error, breaking m68k
all{mod,yes}config builds.

Fix this by stripping simple comments before looking for Linux-specific
integer types.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Thomas Weißschuh 
Link: https://patch.msgid.link/949f096337e28d50510e970ae3ba3ec9c1342ec0.1759753998.git.geert@linux-m68k.org
[nathan: Adjust comment and remove unnecessary escaping from slashes in
         regex]
Signed-off-by: Nathan Chancellor 
Signed-off-by: Sasha Levin

kbuild: hdrcheck: fix cross build with clang

2025-03-13T12:02:18+00:00

[ Upstream commit 02e9a22ceef0227175e391902d8760425fa072c6 ]

The headercheck tries to call clang with a mix of compiler arguments
that don't include the target architecture. When building e.g. x86
headers on arm64, this produces a warning like

   clang: warning: unknown platform, assuming -mfloat-abi=soft

Add in the KBUILD_CPPFLAGS, which contain the target, in order to make it
build properly.

See also 1b71c2fb04e7 ("kbuild: userprogs: fix bitsize and target
detection on clang").

Reviewed-by: Nathan Chancellor 
Fixes: feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Sasha Levin

kbuild: use $(src) instead of $(srctree)/$(src) for source directory

2024-05-09T19:34:52+00:00

Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:

    src := $(obj)

When the kernel is built in a separate output directory, $(src) does
not accurately reflect the source directory location. While Kbuild
resolves this discrepancy by specifying VPATH=$(srctree) to search for
source files, it does not cover all cases. For example, when adding a
header search path for local headers, -I$(srctree)/$(src) is typically
passed to the compiler.

This introduces inconsistency between upstream and downstream Makefiles
because $(src) is used instead of $(srctree)/$(src) for the latter.

To address this inconsistency, this commit changes the semantics of
$(src) so that it always points to the directory in the source tree.

Going forward, the variables used in Makefiles will have the following
meanings:

  $(obj)     - directory in the object tree
  $(src)     - directory in the source tree  (changed by this commit)
  $(objtree) - the top of the kernel object tree
  $(srctree) - the top of the kernel source tree

Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
with $(src).

Signed-off-by: Masahiro Yamada 
Reviewed-by: Nicolas Schier

arch: Remove Itanium (IA-64) architecture

2023-09-11T08:13:17+00:00

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:50+00:00

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:10+00:00

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:10+00:00

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:10+00:00

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:10+00:00

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:10+00:00

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