Re: [PATCH v4 0/3] linux-custom: Split up binaries from kernel headers to kbuild packages

["Koch, Stefan" <stefan-koch@siemens.com>]

On Sun, 2023-12-17 at 17:50 +0100, Jan Kiszka wrote:
> On 21.08.23 15:44, Stefan Koch wrote:
> > Hi
> > 
> > This updated v4 patchset implement suggestions from reviewed v3
> > patchset.
> > It's now a set of five patches:
> > - linux-custom: Split up binaries from kernel headers to kbuild
> > package
> > - linux-custom: Provide host and target specific kernel kbuild
> > packages
> > - docs: Update custom_kernel docs for split up of kernel scripts
> > and tools
> > 
> > The main use-case was to swap out the binaries
> > from the kernel headers into kernel kbuild package.
> > This is introduced by the first commit
> > "Split up binaries from kernel headers to kbuild package"
> > 
> > The second commit "Provide host and target specific kernel kbuild
> > packages"
> > introduces that the binaries could be swapped out into host and
> > target
> > specific kernel kbuild packages.
> > 
> > The main development goals were these:
> > 
> > 1. Solve already known isar custom kernel
> > limitations from doc/custom_kernel.inc
> > - kernel headers package does not support both native
> >   and cross compilation of kernel modules when cross built
> > 
> > 2. Honor recommendations for future from doc/custom_kernel.inc
> > - Generate kernel headers packages for both host and target
> >   when using cross build
> > 
> > 3. Add extensions known from debian kernel packages structure
> > - Generate a kernel headers package without binaries
> > - Create specific kernel kbuild packages that
> >   will ship the "scripts" and "tools" binaries
> > - Use symlinks to point to the "scripts" and "tools" binaries
> > 
> > 4. Be user friendly
> > - Avoid redundant configuration of kernel source definitions with
> > user
> >   actions to enable kbuild package generation
> > - Use already known way to include linux-custom.inc in just one
> >   own bitbake recipe that provides the kernel source definitions
> > - Keep known user behavior for existing build configurations:
> >   just update isar, request "-compat" (and "-native") bitbake
> > targets
> >   and kbuild packages for target and host will be created
> > automatically
> > 
> > Best regards
> > 
> > Stefan
> > 
> > Stefan Koch (3):
> >   linux-custom: Split up binaries from kernel headers to kbuild
> > package
> >   linux-custom: Provide host and target specific kernel kbuild
> > packages
> >   docs: Update custom_kernel docs for split up of kernel scripts
> > and
> >     tools
> > 
> >  doc/custom_kernel.md                          | 16 ++--
> >  .../linux/files/debian/control.tmpl           | 25 ++++++-
> >  .../linux/files/debian/isar/build.tmpl        | 12 ++-
> >  .../linux/files/debian/isar/common.tmpl       | 10 +++
> >  .../linux/files/debian/isar/install.tmpl      | 73 ++++++++++++++-
> > ----
> >  .../linux/files/debian/rules.tmpl             |  2 +-
> >  meta/recipes-kernel/linux/linux-custom.inc    | 53 ++++++++++++--
> >  7 files changed, 155 insertions(+), 36 deletions(-)
> > 
> 
> I'd like to complete this rather soon now because it should allow us
> to
> build and actually use a custom linux-libc-dev - currently only the
> one
> of the target architecture is built, and that can't be installed into
> sbuild-chroot because it conflicts with linux-libc-dev:native.
> 
> What were the plans to revive it? Patch 1 was ready but patch 2
> needed
> to stay away from misusing -compat.
> 
> Jan
> 

Base implementation of new patchset is already finished.
It will soon be published.

Stefan

-- 
Stefan Koch
Siemens AG
www.siemens.com