[GIT PULL] kbuild changes for v6.19

[GIT PULL] kbuild changes for v6.19

[Nicolas Schier]

[-- Attachment #1: Type: text/plain, Size: 5024 bytes --]

Hi Linus,

please pull these update to Kbuild for v6.19.  This is my first pull
request, so please let me know if anything is incorrect and not matching
your standards.

All changes have been in -next, most for several cycles without reported
problems.

Non-native kbuild changes are related to addition of -fms-extensions and
a conversion example; as well as for the userspace CC_CAN_LINK addition.

Thanks and kind regards,
Nicolas


----------------------------------------------------------------

The following changes since commit 211ddde0823f1442e4ad052a2f30f050145ccada:

  Linux 6.18-rc2 (2025-10-19 15:19:16 -1000)

are available in the Git repository at:

  ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git tags/kbuild-6.19-1

for you to fetch changes up to 2a9c8c0b59d366acabb8f891e84569376f3e2709:

  kbuild: add target to build a cpio containing modules (2025-11-26 21:56:14 +0100)

----------------------------------------------------------------
Kbuild updates for v6.19

  - Enable -fms-extensions, allowing anonymous use of tagged struct or
    union in struct/union (tag kbuild-ms-extensions-6.19).  An exemplary
    conversion patch is added here, too (btrfs).

  - Introduce architecture-specific CC_CAN_LINK and flags for userprogs

  - Add new packaging target 'modules-cpio-pkg' for building a initramfs
    cpio w/ kmods

  - Handle included .c files in gen_compile_commands

  - Minor kbuild changes:
    - Use objtree for module signing key path, fixing oot kmod signing
    - Improve documentation of KBUILD_BUILD_TIMESTAMP
    - Reuse KBUILD_USERCFLAGS for UAPI, instead of defining twice
    - Rename scripts/Makefile.extrawarn to Makefile.warn
    - Drop obsolete types.h check from headers_check.pl
    - Remove outdated config leak ignore entries

Signed-off-by: Nicolas Schier <nsc@kernel.org>

----------------------------------------------------------------
Ahmad Fatoum (1):
      initramfs: add gen_init_cpio to hostprogs unconditionally

Gang Yan (1):
      kbuild: doc: improve KBUILD_BUILD_TIMESTAMP documentation

Mikhail Malyshev (1):
      kbuild: Use objtree for module signing key path

Nathan Chancellor (4):
      jfs: Rename _inline to avoid conflict with clang's '-fms-extensions'
      kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS
      kbuild: Rename Makefile.extrawarn to Makefile.warn
      kbuild: uapi: Drop types.h check from headers_check.pl

Nicolas Schier (3):
      Merge tag 'kbuild-ms-extensions-6.19' into kbuild-next
      MAINTAINERS, .mailmap: Update mail address for Nicolas Schier
      scripts: headers_install.sh: Remove two outdated config leak ignore entries

Pat Somaru (1):
      scripts/clang-tools: Handle included .c files in gen_compile_commands

Rasmus Villemoes (2):
      Kbuild: enable -fms-extensions
      btrfs: send: make use of -fms-extensions for defining struct fs_path

Sascha Hauer (1):
      kbuild: add target to build a cpio containing modules

Thomas Weißschuh (4):
      kbuild: uapi: reuse KBUILD_USERCFLAGS
      kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings
      init: deduplicate cc-can-link.sh invocations
      kbuild: allow architectures to override CC_CAN_LINK

 .mailmap                                      |   4 +-
 Documentation/kbuild/kbuild.rst               |  10 +-
 MAINTAINERS                                   |   2 +-
 Makefile                                      |  18 +++-
 arch/arm64/kernel/vdso32/Makefile             |   3 +-
 arch/loongarch/vdso/Makefile                  |   2 +-
 arch/parisc/boot/compressed/Makefile          |   2 +-
 arch/powerpc/boot/Makefile                    |   3 +-
 arch/s390/Makefile                            |   3 +-
 arch/s390/purgatory/Makefile                  |   3 +-
 arch/x86/Makefile                             |   4 +-
 arch/x86/boot/compressed/Makefile             |   7 +-
 drivers/firmware/efi/libstub/Makefile         |   4 +-
 drivers/gpu/drm/Makefile                      |   2 +-
 fs/btrfs/send.c                               |  39 ++++----
 fs/jfs/jfs_incore.h                           |   6 +-
 init/Kconfig                                  |   8 +-
 scripts/Kconfig.include                       |   3 +
 scripts/Makefile.modinst                      |   2 +-
 scripts/Makefile.package                      |  20 ++++
 scripts/{Makefile.extrawarn => Makefile.warn} |   4 +-
 scripts/cc-can-link.sh                        |   2 +-
 scripts/clang-tools/gen_compile_commands.py   | 135 ++++++++++++++++++++++++--
 scripts/headers_install.sh                    |   2 -
 usr/Makefile                                  |   4 +-
 usr/include/Makefile                          |  11 +--
 usr/include/headers_check.pl                  |  63 ------------
 27 files changed, 236 insertions(+), 130 deletions(-)
 rename scripts/{Makefile.extrawarn => Makefile.warn} (98%)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [GIT PULL] kbuild changes for v6.19

[pr-tracker-bot]

The pull request you sent on Mon, 1 Dec 2025 16:37:38 +0100:

> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git tags/kbuild-6.19-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2ddcf4962c1834a14340a1f50afafc3276c015bd

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] kbuild changes for v6.19

[Dmitry Vyukov]

On Mon, 1 Dec 2025 at 16:38, Nicolas Schier <nsc@kernel.org> wrote:
>
> Hi Linus,
>
> please pull these update to Kbuild for v6.19.  This is my first pull
> request, so please let me know if anything is incorrect and not matching
> your standards.
>
> All changes have been in -next, most for several cycles without reported
> problems.
>
> Non-native kbuild changes are related to addition of -fms-extensions and
> a conversion example; as well as for the userspace CC_CAN_LINK addition.
>
> Thanks and kind regards,
> Nicolas
>
>
> ----------------------------------------------------------------
>
> The following changes since commit 211ddde0823f1442e4ad052a2f30f050145ccada:
>
>   Linux 6.18-rc2 (2025-10-19 15:19:16 -1000)
>
> are available in the Git repository at:
>
>   ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git tags/kbuild-6.19-1
>
> for you to fetch changes up to 2a9c8c0b59d366acabb8f891e84569376f3e2709:
>
>   kbuild: add target to build a cpio containing modules (2025-11-26 21:56:14 +0100)
>
> ----------------------------------------------------------------
> Kbuild updates for v6.19
>
>   - Enable -fms-extensions, allowing anonymous use of tagged struct or
>     union in struct/union (tag kbuild-ms-extensions-6.19).  An exemplary
>     conversion patch is added here, too (btrfs).
>
>   - Introduce architecture-specific CC_CAN_LINK and flags for userprogs
>
>   - Add new packaging target 'modules-cpio-pkg' for building a initramfs
>     cpio w/ kmods
>
>   - Handle included .c files in gen_compile_commands
>
>   - Minor kbuild changes:
>     - Use objtree for module signing key path, fixing oot kmod signing
>     - Improve documentation of KBUILD_BUILD_TIMESTAMP
>     - Reuse KBUILD_USERCFLAGS for UAPI, instead of defining twice
>     - Rename scripts/Makefile.extrawarn to Makefile.warn
>     - Drop obsolete types.h check from headers_check.pl
>     - Remove outdated config leak ignore entries
>
> Signed-off-by: Nicolas Schier <nsc@kernel.org>
>
> ----------------------------------------------------------------
> Ahmad Fatoum (1):
>       initramfs: add gen_init_cpio to hostprogs unconditionally
>
> Gang Yan (1):
>       kbuild: doc: improve KBUILD_BUILD_TIMESTAMP documentation
>
> Mikhail Malyshev (1):
>       kbuild: Use objtree for module signing key path
>
> Nathan Chancellor (4):
>       jfs: Rename _inline to avoid conflict with clang's '-fms-extensions'
>       kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS
>       kbuild: Rename Makefile.extrawarn to Makefile.warn
>       kbuild: uapi: Drop types.h check from headers_check.pl
>
> Nicolas Schier (3):
>       Merge tag 'kbuild-ms-extensions-6.19' into kbuild-next
>       MAINTAINERS, .mailmap: Update mail address for Nicolas Schier
>       scripts: headers_install.sh: Remove two outdated config leak ignore entries
>
> Pat Somaru (1):
>       scripts/clang-tools: Handle included .c files in gen_compile_commands

/\/\/\/\/\/\/\

This commit breaks invocation of clang tools for me.

For example I now have this fake entry for mock_uncore.c which
pretends to produce intel_uncore.o (along with 2 other commands which
produce the same object file):

  {
    "command": "clang -Wp,-MMD,drivers/gpu/drm/i915/.intel_uncore.o.d
-nostdinc -Iarch/x86/include -I./arch/x86/include/generated -Iinclude
-I./include -Iarch/x86/include/uapi
-I./arch/x86/include/generated/uapi -Iinclude/uapi
-I./include/generated/uapi -include include/linux/compiler-version.h
-include include/linux/kconfig.h -include
include/linux/compiler_types.h -D__KERNEL__ --target=x86_64-linux-gnu
-fintegrated-as -Werror=unknown-warning-option
-Werror=ignored-optimization-argument -Werror=option-ignored
-Werror=unused-command-line-argument -fmacro-prefix-map== -std=gnu11
-fshort-wchar -funsigned-char -fno-common -fno-PIE
-fno-strict-aliasing -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
-mno-sse4a -fcf-protection=branch -fno-jump-tables -m64
-falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mstack-alignment=8
-mskip-rax-setup -march=x86-64 -mtune=generic -mno-red-zone
-mcmodel=kernel -mstack-protector-guard-reg=gs
-mstack-protector-guard-symbol=__ref_stack_chk_guard -Wno-sign-compare
-fno-asynchronous-unwind-tables -mretpoline-external-thunk
-mindirect-branch-cs-prefix -mfunction-return=thunk-extern
-fpatchable-function-entry=16,16 -fno-delete-null-pointer-checks -O2
-fstack-protector-strong -fomit-frame-pointer
-ftrivial-auto-var-init=zero -fno-stack-clash-protection
-falign-functions=16 -fstrict-flex-arrays=3 -fms-extensions
-fno-strict-overflow -fno-stack-check -fno-builtin-wcslen -Wall
-Wextra -Wundef -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=return-type -Werror=strict-prototypes
-Wno-format-security -Wno-trigraphs -Wno-frame-address
-Wno-address-of-packed-member -Wmissing-declarations
-Wmissing-prototypes -Wframe-larger-than=2048 -Wno-gnu
-Wno-microsoft-anon-tag -Wno-format-overflow-non-kprintf
-Wno-format-truncation-non-kprintf -Wno-pointer-sign
-Wcast-function-type -Wimplicit-fallthrough -Werror=date-time
-Werror=incompatible-pointer-types -Wenum-conversion -Wunused
-Wno-unused-but-set-variable -Wno-unused-const-variable
-Wno-format-overflow -Wno-override-init -Wno-pointer-to-enum-cast
-Wno-tautological-constant-out-of-range-compare -Wno-unaligned-access
-Wno-enum-compare-conditional -Wno-missing-field-initializers
-Wno-type-limits -Wno-shift-negative-value -Wno-enum-enum-conversion
-Wno-sign-compare -Wno-unused-parameter -g -gdwarf-4 -Wextra -Wunused
-Wno-unused-parameter -Wmissing-format-attribute
-Wold-style-definition -Wmissing-include-dirs
-Wunused-but-set-variable -Wunused-const-variable -Wformat-overflow
-Wno-missing-field-initializers -Wno-type-limits
-Wno-shift-negative-value -Wno-sign-compare -Wformat-truncation -DI915
-Idrivers/gpu/drm/i915    -fsanitize=kernel-address -mllvm
-asan-mapping-offset=0xdffffc0000000000  -mllvm
-asan-instrumentation-with-call-threshold=10000  -mllvm -asan-stack=1
  -mllvm -asan-globals=1  -mllvm -asan-kernel-mem-intrinsic-prefix=1
-fsanitize=array-bounds -fsanitize=shift
-fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp
-Idrivers/gpu/drm/i915 -Idrivers/gpu/drm/i915
-DKBUILD_MODFILE='\"drivers/gpu/drm/i915/i915\"'
-DKBUILD_BASENAME='\"intel_uncore\"' -DKBUILD_MODNAME='\"i915\"'
-D__KBUILD_MODNAME=i915 -c -o drivers/gpu/drm/i915/intel_uncore.o
-include linux/pm_runtime.h -include drm/drm_managed.h -include
drm/drm_print.h -include
drivers/gpu/drm/i915/display/intel_display_core.h -include
drivers/gpu/drm/i915/gt/intel_engine_regs.h -include
drivers/gpu/drm/i915/gt/intel_gt.h -include
drivers/gpu/drm/i915/gt/intel_gt_regs.h -include
drivers/gpu/drm/i915/i915_drv.h -include
drivers/gpu/drm/i915/i915_iosf_mbi.h -include
drivers/gpu/drm/i915/i915_reg.h -include
drivers/gpu/drm/i915/i915_vgpu.h -include
drivers/gpu/drm/i915/i915_wait_util.h -include
drivers/gpu/drm/i915/i915_mmio_range.h -include
drivers/gpu/drm/i915/intel_uncore_trace.h
drivers/gpu/drm/i915/selftests/mock_uncore.c",
    "directory": "build/b405de752a64d7657dcad6b5042d7bf4327a3bd8",
    "file": "drivers/gpu/drm/i915/selftests/mock_uncore.c"
  },


An attempt to invoke a clang tool using this database legitimately
fails with the following errors (the file is not supposed and can't
compile on its own):

clang-tool: drivers/gpu/drm/i915/selftests/mock_uncore.c: exit status 1
drivers/gpu/drm/i915/selftests/mock_uncore.c:47:2: error: call to
undeclared function 'ASSIGN_RAW_WRITE_MMIO_VFUNCS'; ISO C99 and later
do not support implicit function declarations
[-Wimplicit-function-declaration]
   47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
      |         ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:47:39: error: use of
undeclared identifier 'nop'; did you mean 'nopv'?
   47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
      |                                              ^~~
      |                                              nopv
/arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
   71 | extern bool nopv;
      |             ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:48:2: error: call to
undeclared function 'ASSIGN_RAW_READ_MMIO_VFUNCS'; ISO C99 and later
do not support implicit function declarations
[-Wimplicit-function-declaration]
   48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
      |         ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:48:38: error: use of
undeclared identifier 'nop'; did you mean 'nopv'?
   48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
      |                                             ^~~
      |                                             nopv
/arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
   71 | extern bool nopv;
      |             ^
4 errors generated.
Error while processing /drivers/gpu/drm/i915/selftests/mock_uncore.c.


What am I doing wrong?

#regzbot introduced: 9362d34acf91a706c543d919ade3e651b9bd2d6f
#regzbot title: scripts/clang-tools: included .c files don't compile

Re: [GIT PULL] kbuild changes for v6.19

[Nathan Chancellor]

On Wed, Dec 17, 2025 at 05:16:02PM +0900, Dmitry Vyukov wrote:
> On Mon, 1 Dec 2025 at 16:38, Nicolas Schier <nsc@kernel.org> wrote:
> > Pat Somaru (1):
> >       scripts/clang-tools: Handle included .c files in gen_compile_commands
> 
> /\/\/\/\/\/\/\
> 
> This commit breaks invocation of clang tools for me.
> 
> For example I now have this fake entry for mock_uncore.c which
> pretends to produce intel_uncore.o (along with 2 other commands which
> produce the same object file):
...
> An attempt to invoke a clang tool using this database legitimately
> fails with the following errors (the file is not supposed and can't
> compile on its own):
> 
> clang-tool: drivers/gpu/drm/i915/selftests/mock_uncore.c: exit status 1
> drivers/gpu/drm/i915/selftests/mock_uncore.c:47:2: error: call to
> undeclared function 'ASSIGN_RAW_WRITE_MMIO_VFUNCS'; ISO C99 and later
> do not support implicit function declarations
> [-Wimplicit-function-declaration]
>    47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
>       |         ^
> drivers/gpu/drm/i915/selftests/mock_uncore.c:47:39: error: use of
> undeclared identifier 'nop'; did you mean 'nopv'?
>    47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
>       |                                              ^~~
>       |                                              nopv
> /arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
>    71 | extern bool nopv;
>       |             ^
> drivers/gpu/drm/i915/selftests/mock_uncore.c:48:2: error: call to
> undeclared function 'ASSIGN_RAW_READ_MMIO_VFUNCS'; ISO C99 and later
> do not support implicit function declarations
> [-Wimplicit-function-declaration]
>    48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
>       |         ^
> drivers/gpu/drm/i915/selftests/mock_uncore.c:48:38: error: use of
> undeclared identifier 'nop'; did you mean 'nopv'?
>    48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
>       |                                             ^~~
>       |                                             nopv
> /arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
>    71 | extern bool nopv;
>       |             ^
> 4 errors generated.
> Error while processing /drivers/gpu/drm/i915/selftests/mock_uncore.c.
> 
> 
> What am I doing wrong?

Nothing. As you note, ASSIGN_RAW_WRITE_MMIO_VFUNCS is defined in
drivers/gpu/drm/i915/intel_uncore.c but it is used in
drivers/gpu/drm/i915/selftests/mock_uncore.c, which is not designed to
be built standalone. We could potentially move
ASSIGN_RAW_WRITE_MMIO_VFUNCS into a common header to avoid this but I
think I would rather just revert 9362d34acf91, as I already figured that
this was going to be fragile:

  https://lore.kernel.org/20251007163338.GA547361@ax162/

I would rather discourage including .c files if folks want clangd to
work properly since this seems fundamentally unsolvable if developers
have written .c files in this manner. I am open to other thoughts
though.

Cheers,
Nathan

Re: [GIT PULL] kbuild changes for v6.19

[Dmitry Vyukov]

On Wed, 17 Dec 2025 at 09:32, Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Wed, Dec 17, 2025 at 05:16:02PM +0900, Dmitry Vyukov wrote:
> > On Mon, 1 Dec 2025 at 16:38, Nicolas Schier <nsc@kernel.org> wrote:
> > > Pat Somaru (1):
> > >       scripts/clang-tools: Handle included .c files in gen_compile_commands
> >
> > /\/\/\/\/\/\/\
> >
> > This commit breaks invocation of clang tools for me.
> >
> > For example I now have this fake entry for mock_uncore.c which
> > pretends to produce intel_uncore.o (along with 2 other commands which
> > produce the same object file):
> ...
> > An attempt to invoke a clang tool using this database legitimately
> > fails with the following errors (the file is not supposed and can't
> > compile on its own):
> >
> > clang-tool: drivers/gpu/drm/i915/selftests/mock_uncore.c: exit status 1
> > drivers/gpu/drm/i915/selftests/mock_uncore.c:47:2: error: call to
> > undeclared function 'ASSIGN_RAW_WRITE_MMIO_VFUNCS'; ISO C99 and later
> > do not support implicit function declarations
> > [-Wimplicit-function-declaration]
> >    47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
> >       |         ^
> > drivers/gpu/drm/i915/selftests/mock_uncore.c:47:39: error: use of
> > undeclared identifier 'nop'; did you mean 'nopv'?
> >    47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
> >       |                                              ^~~
> >       |                                              nopv
> > /arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
> >    71 | extern bool nopv;
> >       |             ^
> > drivers/gpu/drm/i915/selftests/mock_uncore.c:48:2: error: call to
> > undeclared function 'ASSIGN_RAW_READ_MMIO_VFUNCS'; ISO C99 and later
> > do not support implicit function declarations
> > [-Wimplicit-function-declaration]
> >    48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
> >       |         ^
> > drivers/gpu/drm/i915/selftests/mock_uncore.c:48:38: error: use of
> > undeclared identifier 'nop'; did you mean 'nopv'?
> >    48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
> >       |                                             ^~~
> >       |                                             nopv
> > /arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
> >    71 | extern bool nopv;
> >       |             ^
> > 4 errors generated.
> > Error while processing /drivers/gpu/drm/i915/selftests/mock_uncore.c.
> >
> >
> > What am I doing wrong?
>
> Nothing. As you note, ASSIGN_RAW_WRITE_MMIO_VFUNCS is defined in
> drivers/gpu/drm/i915/intel_uncore.c but it is used in
> drivers/gpu/drm/i915/selftests/mock_uncore.c, which is not designed to
> be built standalone. We could potentially move
> ASSIGN_RAW_WRITE_MMIO_VFUNCS into a common header to avoid this but I
> think I would rather just revert 9362d34acf91, as I already figured that
> this was going to be fragile:
>
>   https://lore.kernel.org/20251007163338.GA547361@ax162/
>
> I would rather discourage including .c files if folks want clangd to
> work properly since this seems fundamentally unsolvable if developers
> have written .c files in this manner. I am open to other thoughts
> though.

I am not sure what other clang tools are doing, and why they need
this. But FWIW my clang tools don't need it at all. They would index
all files, get source files from AST (which would include included .c
files as well), and work with that index. So they natively "see" and
understand all included .c files.

Re: [GIT PULL] kbuild changes for v6.19

[Dmitry Vyukov]

On Wed, 17 Dec 2025 at 09:39, Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > Pat Somaru (1):
> > > >       scripts/clang-tools: Handle included .c files in gen_compile_commands
> > >
> > > /\/\/\/\/\/\/\
> > >
> > > This commit breaks invocation of clang tools for me.
> > >
> > > For example I now have this fake entry for mock_uncore.c which
> > > pretends to produce intel_uncore.o (along with 2 other commands which
> > > produce the same object file):
> > ...
> > > An attempt to invoke a clang tool using this database legitimately
> > > fails with the following errors (the file is not supposed and can't
> > > compile on its own):
> > >
> > > clang-tool: drivers/gpu/drm/i915/selftests/mock_uncore.c: exit status 1
> > > drivers/gpu/drm/i915/selftests/mock_uncore.c:47:2: error: call to
> > > undeclared function 'ASSIGN_RAW_WRITE_MMIO_VFUNCS'; ISO C99 and later
> > > do not support implicit function declarations
> > > [-Wimplicit-function-declaration]
> > >    47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
> > >       |         ^
> > > drivers/gpu/drm/i915/selftests/mock_uncore.c:47:39: error: use of
> > > undeclared identifier 'nop'; did you mean 'nopv'?
> > >    47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
> > >       |                                              ^~~
> > >       |                                              nopv
> > > /arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
> > >    71 | extern bool nopv;
> > >       |             ^
> > > drivers/gpu/drm/i915/selftests/mock_uncore.c:48:2: error: call to
> > > undeclared function 'ASSIGN_RAW_READ_MMIO_VFUNCS'; ISO C99 and later
> > > do not support implicit function declarations
> > > [-Wimplicit-function-declaration]
> > >    48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
> > >       |         ^
> > > drivers/gpu/drm/i915/selftests/mock_uncore.c:48:38: error: use of
> > > undeclared identifier 'nop'; did you mean 'nopv'?
> > >    48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
> > >       |                                             ^~~
> > >       |                                             nopv
> > > /arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
> > >    71 | extern bool nopv;
> > >       |             ^
> > > 4 errors generated.
> > > Error while processing /drivers/gpu/drm/i915/selftests/mock_uncore.c.
> > >
> > >
> > > What am I doing wrong?
> >
> > Nothing. As you note, ASSIGN_RAW_WRITE_MMIO_VFUNCS is defined in
> > drivers/gpu/drm/i915/intel_uncore.c but it is used in
> > drivers/gpu/drm/i915/selftests/mock_uncore.c, which is not designed to
> > be built standalone. We could potentially move
> > ASSIGN_RAW_WRITE_MMIO_VFUNCS into a common header to avoid this but I
> > think I would rather just revert 9362d34acf91, as I already figured that
> > this was going to be fragile:
> >
> >   https://lore.kernel.org/20251007163338.GA547361@ax162/
> >
> > I would rather discourage including .c files if folks want clangd to
> > work properly since this seems fundamentally unsolvable if developers
> > have written .c files in this manner. I am open to other thoughts
> > though.
>
> I am not sure what other clang tools are doing, and why they need
> this. But FWIW my clang tools don't need it at all. They would index
> all files, get source files from AST (which would include included .c
> files as well), and work with that index. So they natively "see" and
> understand all included .c files.

Yikes! I am trying to workaround this, but this is PITA.
Entries are not in order, + there are now multiple entries for the
same source file (yes, files include themselves). This is plain
broken, and hard to workaround. Even if I find the entry that is
correct, I can't really tell about it to a clang tool since it accepts
just the source file name, and there are multiple entries for the same
file name.

Does anybody see a reasonable way to undo what this commit is doing?

Thinking about this: I think included source files should be treated
as include files by anything, rather than added to the database. They
_are_ include files, and systems should handle include files already.

Re: [GIT PULL] kbuild changes for v6.19

[Nathan Chancellor]

On Wed, Dec 17, 2025 at 11:16:37AM +0100, Dmitry Vyukov wrote:
> Yikes! I am trying to workaround this, but this is PITA.
> Entries are not in order, + there are now multiple entries for the
> same source file (yes, files include themselves). This is plain
> broken, and hard to workaround. Even if I find the entry that is
> correct, I can't really tell about it to a clang tool since it accepts
> just the source file name, and there are multiple entries for the same
> file name.
> 
> Does anybody see a reasonable way to undo what this commit is doing?

Does

  $ git revert 9362d34acf91a706c543d919ade3e651b9bd2d6f

not work for you? It is a clean revert for me.

> Thinking about this: I think included source files should be treated
> as include files by anything, rather than added to the database. They
> _are_ include files, and systems should handle include files already.

The commit message of 9362d34acf91 mentions that clangd does not work
properly with the files that are included in kernel/sched/build_policy.c
(such as kernel/sched/ext.c) because there are no entries for them in
compile_commmands.json (so it does not know how to build them), which is
what 9362d34acf91 was trying to fix. I don't use clangd or
compile_commands.json, so I can't say if there is a way for the tool
itself to fix this. Again, unless Pat can come up with some way to work
around this (which I do not personally see at this point), I think we
would be better off just reverting 9362d34acf91 outright and calling the
situation of including .c files within other .c files broken for
compile_commands.json and returning to the status quo from 6.18 and
earlier.

Cheers,
Nathan

Re: [GIT PULL] kbuild changes for v6.19

[Dmitry Vyukov]

On Wed, 17 Dec 2025 at 11:45, Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Wed, Dec 17, 2025 at 11:16:37AM +0100, Dmitry Vyukov wrote:
> > Yikes! I am trying to workaround this, but this is PITA.
> > Entries are not in order, + there are now multiple entries for the
> > same source file (yes, files include themselves). This is plain
> > broken, and hard to workaround. Even if I find the entry that is
> > correct, I can't really tell about it to a clang tool since it accepts
> > just the source file name, and there are multiple entries for the same
> > file name.
> >
> > Does anybody see a reasonable way to undo what this commit is doing?
>
> Does
>
>   $ git revert 9362d34acf91a706c543d919ade3e651b9bd2d6f
>
> not work for you? It is a clean revert for me.

I am not typing commands in the console, I work on an automated system
that does not have a notion of "also do these custom changes to the
source tree at this particular point in the process".

> > Thinking about this: I think included source files should be treated
> > as include files by anything, rather than added to the database. They
> > _are_ include files, and systems should handle include files already.
>
> The commit message of 9362d34acf91 mentions that clangd does not work
> properly with the files that are included in kernel/sched/build_policy.c
> (such as kernel/sched/ext.c) because there are no entries for them in
> compile_commmands.json (so it does not know how to build them),

The same stands for e.g. include/linux/sched.h.
kernel/sched/ext.c is just not a source file, it is a header file effectively.

> which is
> what 9362d34acf91 was trying to fix. I don't use clangd or
> compile_commands.json, so I can't say if there is a way for the tool
> itself to fix this. Again, unless Pat can come up with some way to work
> around this (which I do not personally see at this point), I think we
> would be better off just reverting 9362d34acf91 outright and calling the
> situation of including .c files within other .c files broken for
> compile_commands.json and returning to the status quo from 6.18 and
> earlier.
>
> Cheers,
> Nathan

Re: [GIT PULL] kbuild changes for v6.19

[Pat Somaru]

Hi All,

>> itself to fix this. Again, unless Pat can come up with some way to work
>> around this (which I do not personally see at this point), I think we
>> would be better off just reverting 9362d34acf91 outright and calling the
>> situation of including .c files within other .c files broken for
>> compile_commands.json and returning to the status quo from 6.18 and
>> earlier.

I would say revert this.

When I was testing this change, I wrote a script to non-interactively
run clangd against all the files in the kernel individually and report if 
there were more errors or fewer and how many files clangd gave up on indexing.

I vaguely recall this script reported there were more errors overall, but also
that there were fewer files which clangd gave up on indexing (i.e. fewer
files where LSP more/less outright does not work)/more files processed
overall.

My understanding of that output was "folks's ide's/clangd works on more files
with this, but there are more errors overall because fewer files are
treated as totally broken/given up on by clangd".

If there are only a handful of problematic files with this, I can see if
there are some common patterns (such as c files including themselves) which 
could be accounted for in the script, but if the outputs of
gen_compile_commands are used as inputs to further automation, both issues 
with the script itself and those in files previously excluded due to the 
omission of compilation database entries are going to be surfaced by this, and
I'm not super confident I could come up with a complete set of fixes for the
latter.

Have a good day,
Pat

On Wed Dec 17, 2025 at 7:07 AM EST, Dmitry Vyukov wrote:
> On Wed, 17 Dec 2025 at 11:45, Nathan Chancellor <nathan@kernel.org> wrote:
>>
>> On Wed, Dec 17, 2025 at 11:16:37AM +0100, Dmitry Vyukov wrote:
>> > Yikes! I am trying to workaround this, but this is PITA.
>> > Entries are not in order, + there are now multiple entries for the
>> > same source file (yes, files include themselves). This is plain
>> > broken, and hard to workaround. Even if I find the entry that is
>> > correct, I can't really tell about it to a clang tool since it accepts
>> > just the source file name, and there are multiple entries for the same
>> > file name.
>> >
>> > Does anybody see a reasonable way to undo what this commit is doing?
>>
>> Does
>>
>>   $ git revert 9362d34acf91a706c543d919ade3e651b9bd2d6f
>>
>> not work for you? It is a clean revert for me.
>
> I am not typing commands in the console, I work on an automated system
> that does not have a notion of "also do these custom changes to the
> source tree at this particular point in the process".
>
>> > Thinking about this: I think included source files should be treated
>> > as include files by anything, rather than added to the database. They
>> > _are_ include files, and systems should handle include files already.
>>
>> The commit message of 9362d34acf91 mentions that clangd does not work
>> properly with the files that are included in kernel/sched/build_policy.c
>> (such as kernel/sched/ext.c) because there are no entries for them in
>> compile_commmands.json (so it does not know how to build them),
>
> The same stands for e.g. include/linux/sched.h.
> kernel/sched/ext.c is just not a source file, it is a header file effectively.
>
>> which is
>> what 9362d34acf91 was trying to fix. I don't use clangd or
>> compile_commands.json, so I can't say if there is a way for the tool
>> itself to fix this. Again, unless Pat can come up with some way to work
>> around this (which I do not personally see at this point), I think we
>> would be better off just reverting 9362d34acf91 outright and calling the
>> situation of including .c files within other .c files broken for
>> compile_commands.json and returning to the status quo from 6.18 and
>> earlier.
>>
>> Cheers,
>> Nathan