Dear Maintainer,

The linux-headers packages for kernel version 6.6 seem to depend on the corresponding
linux-image packages, but I believe that this should not be the case (and was not the
case in previous versions). It should be possible to install the header files for
a particular kernel version (eg: to allow for modules to be built for that version,
which is my use case) without requiring the kernel image to be installed.

I think the headers packages should depend on a suitable version of linux-kbuild and
any necessary glibc headers or other build artifacts, but not on linux-image-*

Many thanks,

Colm

Some previous versions, for contrast:

% apt-cache depends linux-headers-6.5.0-0.deb12.4-amd64
linux-headers-6.5.0-0.deb12.4-amd64
  Depends: linux-headers-6.5.0-0.deb12.4-common
  Depends: linux-kbuild-6.5.0-0.deb12.4
  Depends: linux-compiler-gcc-12-x86

% apt-cache depends linux-headers-6.1.0-18-amd64
linux-headers-6.1.0-18-amd64
  Depends: linux-headers-6.1.0-18-common
  Depends: linux-kbuild-6.1
  Depends: linux-compiler-gcc-12-x86

Control: tags -1 wontfix

It should.  The build wants the image available (it does not really fail
without, but lacks stuff) and we need some dependency to keep image and
headers in sync for people using dkms.

Bastian

Why was this never the case before? And can you be more precise about what
"stuff" is missing? Is there a previous bug report I can reference?

DKMS should handle its own dependencies, I'd have thought - I see a clear
use case for installing header files without the corresponding images.

        Colm

It complains loudly about BTF.

Sure, but installing the image does not break much.  But not installing
the headers breaks much.

Maybe you can provide a proposal how that would work?

Bastian

lacks stuff) and we need some dependency to keep image and headers in sync
for people using dkms.

To be honest, "it does not really fail without, but lacks stuff" seems like
the use case that "Recommends:" (or even "Suggests:") was designed for,
rather than "Depends:", don't you agree?

I'm not sure, of course, what problem is being addressed here; it's
possible that there's a more elegant solution available. Is there a
previous bug describing the problem?

My concern is that I have a specific build server which builds kernels and
modules for other machines in a farm. It needs to have the header files for
specific target kernel versions installed, but it is not sensible to have
the corresponding image packages installed (in many cases, those images
wouldn't even run on this build server).

        Colm

On Thu, 29 Feb 2024 12:25:27 +0100 Bastian Blank <waldi@debian.org> wrote:
about what

With the new vmlinux.h shipped in the headers package, the BTF case
should be covered. I think we should nudge packages to use that, rather
than looking at the kernel image, or worse sysfs from the running
kernel, which is completely wrong for obvious reasons.

The relevant code in Linux is:

| quiet_cmd_btf_ko = BTF [M] $@
|       cmd_btf_ko =                                                      \
|         if [ ! -f vmlinux ]; then                                       \
|                 printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \
|         else                                                            \
|                 LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \
|                 $(RESOLVE_BTFIDS) -b vmlinux $@;                        \
|         fi;

Which change is needed here to use vmlinux.h instead?

Bastian

 \
\
unavailability of vmlinux\n" $@ 1>&2; \
 \
--btf_base vmlinux $@; \
 \

My understanding is that you don't need this command at all; the included
vmlinux.h already contains the necessary type definitions for libbpf, for
the kernel source version in question - ie: instead of needing to run
pahole or bpftool to extract these definitions from a specific vmlinux
image, this file is distributed with them already included.


Colm

On Thu, 29 Feb 2024 14:23:05 +0000 Colm Buckley <colm@tuatha.org> wrote:
wrote:
case
$(PAHOLE_FLAGS)
included
for
vmlinux

Yes precisely, the bpf program source can just include vmlinux.h and it
should build and run as expected.

As per the discussion in
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1005 - once
vmlinux.h is included with linux-headers, the warning about cmd_btf_ko etc.
should be harmless, as that file should already be available (ie: there's
no need to generate it again as part of kernel build). Am I missing
something else? I confess I have only a very small amount of experience
with BPF code; I played with building a few modules, but I don't use it
regularly.

Colm

But we where talking about kernel modules.

Bastian

There are kernel modules using BPF stuff? Never seen one, do you have
an example?

No idea, but they get linked BTF information, so you could use them.

Bastian

On Mon, 4 Mar 2024 13:54:49 +0100 Bastian Blank <waldi@debian.org> wrote:
have

Sure, but it's a bit of an unusual case to say the least, and I'm not
aware of dkms packages in Debian doing that (happy to stand corrected
if that's not the case).

So surely any out-of-distro dkms package doing that should just ensure
they pull in the dependencies they need for it?

Assuming it's even needed. As far as I understand, the point of
vmlinux.h is that it gives the equivalent information generated from
BTF.

The issue is that pulling the headers package also pulls the image,
initramfs and all that machinery. We are going to depend on the headers
package in src:systemd from the next release to get the vmlinux.h, and
pulling all that stuff too adds considerable weight to the build
dependency installation job.

I am assuming that the original intent of adding linux-image-* as a
dependency was to prevent the "Skipping BTF generation for %s due to
unavailability of vmlinux" warning from being printed; is that a fair
assumption?

I am quite sure that this will not cause problems because of the decision
in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1005 to
include vmlinux.h in the headers package. This file is the thing which is
generated by "cmd_btf_ko" in the upstream kernel build, so any module or
userspace program which depends on BPF will be able to pull the necessary
information from that file.

As Luca says, adding the image and associated machinery as a dependency to
a source file is a very heavy-handed way to solve quite a niche problem
(which I don't think even is a problem). It makes assumptions which I
don't think hold true in many cases; especially that the system being
used to build a kernel or kernel module is the same as the system which
will be running it (or even have the same CPU architecture).

Any DKMS or other out of tree packages which require the Linux image to
be installed should declare that dependency themselves; I am pretty sure
that declaring it here is not the right thing.

        Colm

Hey folks -

I see that linux-headers-* has been promoted to 6.6 in the BPO channel, but
this dependency is still in place.
Is it really the case that we want to drag in the image binaries and other
machinery as a dependency for a source package like linux-headers.
I feel that the BPF use case should really be addressed using vmlinux.h
(the "skipping BTF generation" message should be ignored as all of this
information *should* be included in vmlinux.h).
Any further thoughts?

Colm

Can I suggest in the interim that Depends: be replaced with Recommends:
or Suggests: given that most installations won't actually need the image
package?

    Colm