APPLIED/Cmt: [PATCH noble] UBUNTU: [Packaging] add linux-bpf-dev package

Luca Boccassi luca.boccassi at gmail.com
Wed Jan 15 16:18:47 UTC 2025


On Wed, 15 Jan 2025 at 16:14, Juerg Haefliger
<juerg.haefliger at canonical.com> wrote:
>
> On Wed, 15 Jan 2025 15:13:03 +0000
> Luca Boccassi <luca.boccassi at gmail.com> wrote:
>
> > On Mon, 18 Nov 2024 at 07:31, Roxana Nicolescu
> > <roxana.nicolescu at canonical.com> wrote:
> > >
> > >
> > > On 18/10/2024 20:55, luca.boccassi at gmail.com wrote:
> > > > From: Luca Boccassi <bluca at debian.org>
> > > >
> > > > BugLink: https://bugs.launchpad.net/bugs/2050083
> > > >
> > > > Add a new binary linux-bpf-dev package that ships a generated vmlinux.h
> > > > header. This can be used by packages building CO-RE BPF programs instead
> > > > of generating it at build time based on the kernel running on the package
> > > > build system, which might or might not match the kernel that is actually
> > > > shipped. It ensures that a matching header can always be used.
> > > >
> > > > Matches changes in Debian, including the package name and header installation
> > > > location, so that we do not have to ifdef:
> > > >
> > > > https://salsa.debian.org/kernel-team/linux/-/commit/f52d006f3915ac4358dc8c98aa417477ebee026e
> > > >
> > > > This is already used by systemd to build various CO-RE programs, and
> > > > right now on Ubuntu due to the lack of this package the header is
> > > > generated from sysfs in the build system where the systemd packages are
> > > > built.
> > > >
> > > > Signed-off-by: Luca Boccassi <bluca at debian.org>
> > > > ---
> > > > This has been in Oracular for a while, if possible it would be great to have the
> > > > new package also in Noble, so that we can use it in the systemd upstream build
> > > > and CI.
> > > >
> > > >   debian/control.d/linux-bpf-dev.stub | 7 +++++++
> > > >   debian/rules                        | 1 +
> > > >   debian/rules.d/2-binary-arch.mk     | 8 ++++++++
> > > >   3 files changed, 16 insertions(+)
> > > >   create mode 100644 debian/control.d/linux-bpf-dev.stub
> > > >
> > > > diff --git a/debian/control.d/linux-bpf-dev.stub b/debian/control.d/linux-bpf-dev.stub
> > > > new file mode 100644
> > > > index 000000000000..2967299aec18
> > > > --- /dev/null
> > > > +++ b/debian/control.d/linux-bpf-dev.stub
> > > > @@ -0,0 +1,7 @@
> > > > +Package: linux-bpf-dev
> > > > +Architecture: amd64 armhf arm64 i386 ppc64el riscv64 s390x
> > > > +Depends: ${misc:Depends}
> > > > +Multi-Arch: same
> > > > +Description: Headers for BPF development
> > > > + The vmlinux.h header is provided to allow userspace to build BPF CO-RE
> > > > + programs targeting the packaged kernel.
> > > > diff --git a/debian/rules b/debian/rules
> > > > index 43eae8d5aaa8..5fd39b2b0bcc 100755
> > > > --- a/debian/rules
> > > > +++ b/debian/rules
> > > > @@ -175,6 +175,7 @@ ifeq ($(src_pkg_name),linux)
> > > >       control_files += debian/control.d/linux-tools-host.stub
> > > >       control_files += debian/control.d/linux-source.stub
> > > >       control_files += debian/control.d/linux-doc.stub
> > > > +     control_files += debian/control.d/linux-bpf-dev.stub
> > > >   endif
> > > >
> > > >   # Calculate Ubuntu Compatible Signing levels
> > > > diff --git a/debian/rules.d/2-binary-arch.mk b/debian/rules.d/2-binary-arch.mk
> > > > index fe66f8a0c088..9958f9bcfa22 100644
> > > > --- a/debian/rules.d/2-binary-arch.mk
> > > > +++ b/debian/rules.d/2-binary-arch.mk
> > > > @@ -618,6 +618,9 @@ endif
> > > >   ifeq ($(do_cloud_tools),true)
> > > >       $(call dh_all,$(pkgcloud))
> > > >   endif
> > > > +ifeq ($(do_tools_bpftool),true)
> > > > +     $(call if_package, linux-bpf-dev, $(call dh_all,linux-bpf-dev))
> > > > +endif
> > > >
> > > >   #
> > > >   # per-architecture packages
> > > > @@ -670,6 +673,7 @@ endif
> > > >   ifeq ($(do_tools_bpftool),true)
> > > >       mv $(builddirpa)/tools/bpf/bpftool/vmlinux $(builddirpa)/vmlinux
> > > >       $(kmake) CROSS_COMPILE=$(CROSS_COMPILE) -C $(builddirpa)/tools/bpf/bpftool
> > > > +     $(builddirpa)/tools/bpf/bpftool/bpftool btf dump file $(builddirpa)/vmlinux format c > $(builddirpa)/vmlinux.h
> > > >       rm -f $(builddirpa)/vmlinux
> > > >   endif
> > > >   ifeq ($(do_tools_x86),true)
> > > > @@ -722,6 +726,10 @@ endif
> > > >   ifeq ($(do_tools_bpftool),true)
> > > >       install -m755 $(builddirpa)/tools/bpf/bpftool/bpftool $(toolspkgdir)/usr/lib/$(src_pkg_name)-tools-$(abi_release)
> > > >   endif
> > > > +ifeq ($(do_tools_bpftool),true)
> > > > +     install -d -m755 $(CURDIR)/debian/linux-bpf-dev/usr/include/$(DEB_HOST_MULTIARCH)/linux/
> > > > +     install -m644 $(builddirpa)/vmlinux.h $(CURDIR)/debian/linux-bpf-dev/usr/include/$(DEB_HOST_MULTIARCH)/linux/vmlinux.h
> > > > +endif
> > > >   ifeq ($(do_tools_x86),true)
> > > >       install -m755 \
> > > >               $(addprefix $(builddirpa)/tools/power/x86/, x86_energy_perf_policy/x86_energy_perf_policy turbostat/turbostat) \
> > > Applied to noble:linux master-next branch. I included the required
> > > trailing. Thanks!
> >
> > Hi,
> >
> > There have been a few noble-updates uploads of linux since this was
> > added to master-next, but the patch hasn't showed up yet. It's not
> > part of the most recent tag Ubuntu-6.8.0-52.53 for example. Any idea
> > when it will make it into an upload?
> > Thanks!
>
> Note that this packaging is somewhat broken for arm64. We build two flavors on
> arm64 (generic and generic-64k) which means we have two different vmlinux.h
> but we package only one of them in linux-bpf-dev. If you happen to be using
> the 'other' kernel flavor, vmlinux.h won't match. Not sure what you want to
> do with this header file... Maybe it doesn't matter but from a packaging
> point of view this is sub-optimal :-)

It's used to build BPF CO-RE programs for other packages - we use it
in systemd currently for example. In _theory_ it is supposed to be
reasonably compatible across small changes, so different flavours of
the same kernel should be ok for consuming programs, the resulting
compiled BPF program should be compatible with either, and if not, I
think the BPF maintainers would consider it a bug to solve.



More information about the kernel-team mailing list