Re: [OE-core] [PATCH v2 0/3] Fix kernel complementary package installation

[Bruce Ashfield <bruce.ashfield@gmail.com>]

On Sat, Oct 31, 2026 at 7:22 AM Freihofer, Adrian wrote:
>
> There are different use cases:
>    1. working as a developer on the kernel. For this I agree with your
>       statement.
>    2. remote debugging a user space application with a debugger such as
>       the Trace32 which supports seamless stepping into the kernel
>       context of a user space process. For this use case the sources
>       are required on the host as for a dynamically linked library
>       ideally as a -src and -dbg package.
>    3. Installing the package (also possible with a binary package feed)
>       into the rootfs is required for on target debugging and
>       profiling.

Thanks, that's the list I was looking for. 2 and 3 are the concrete use
cases for having the source in a rootfs (or rootfs-dbg), so I've gone
ahead with it (more below).

> Agree. This addresses all use cases by:
>  * devtool modify linux-yocto
>  * IMAGE_INSTALL_DEBUGFS:append = " kernel-dev"
>  * IMAGE_INSTALL:append = " kernel-dev"
>  * opkg install kernel-dev

One correction (so nobody sees this on the list or in the archive
and copies this into a local.conf): kernel-dev is
System.map, the config and Module.symvers. The source package is
kernel-devsrc, and the symbols are kernel-dbg and kernel-vmlinux.

kernel-devsrc also doesn't cover 2 or 3 today. (At risk of stating
what is already well know) It is what's needed to build modules
(headers, Kconfig/Makefiles, scripts), so it has almost no
.c files, and installing it pulls in the tools for "make scripts prepare"
(bc, bison, flex, gcc-plugins, openssl-dev, ...), which people
don't want in rootfs-dbg.

>  - I'll send the kernel.bbclass prefix map change on its own, once
> I've
>    checked SPDX's compiled-sources filter is unaffected (it's the
> only
>    other consumer of the kernel's debugsources list)
>
> I did that a few weeks ago. It's an independent code path.

Thanks. I read through it as well, and agree, the compiled-sources
filter only matches files found in the kernel-source copy, and the
generated files were never in there.

> If we have the 9000+ source files instead of only the 400+ generated
> files, all use cases which I have in mind are addressed. Sounds good.

That's what I've prototyped, based on some patches that I've had around
for several years at this point .. It stays one package (kernel-devsrc)
and one tree at /usr/src/kernel, where the debug info points with the
prefix map. PACKAGECONFIG chooses what goes in it:

  build:   what kernel-devsrc is today, with its RDEPENDS. The default,
           so nothing changes for existing users.
  source:  a curated core (core directories plus the machine's arch),
           and the drivers the build actually compiled, discovered from
           kbuild's .cmd files. No RDEPENDS.
  full:    the whole tree.
  tarball: the whole tree as a tarball, rather than uncompressed. This
           is similar to what other distros have in their linux-source
	   packages

With:

  PACKAGECONFIG:pn-kernel-devsrc = "source"
  IMAGE_INSTALL_DEBUGFS = "kernel-dbg kernel-vmlinux kernel-devsrc"

on qemux86-64 (7.2.13), rootfs-dbg gets the symbols and 254MB of source
at /usr/src/kernel, and nothing else: no build tools come along. All
9016 source files named in the kernel's debug info are there. The only
ones missing are the 592 generated files from the build directory,
which we don't want to ship. The full tree is 1.5GB.

That covers 2 (rootfs-dbg on the host, no path mapping in the debugger)
and 3 (install it in the image or from a feed). "source build" gives
both the source and what's needed to build modules on target.

The package can optionally be versioned (kernel-devsrc-<kver>, with
kernel-devsrc holding just the /usr/src/kernel link), so the source of
more than one kernel can be installed side by side.

One thing to know: if the image itself already installs kernel-devsrc,
IMAGE_INSTALL_DEBUGFS won't put it in rootfs-dbg. rootfs-dbg starts from
the image's package database, so it's seen as already installed, and
only the debug files are copied over. That's how the debug rootfs works
in general, but it'll need documenting.

If that sounds ok, I'll send the prefix map patch, and then the
kernel-devsrc series as an RFC so you can try it with TRACE32.

Bruce