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

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

On Fri, 2023-03-17 at 09:06 +0100, Jan Kiszka wrote:
> On 17.03.23 08:41, Uladzimir Bely wrote:
> > In mail from Tuesday, 20 December 2022 20:09:27 +03 user Koch,
> > Stefan wrote:
> > > Hi
> > > 
> > > This updated v2 patchset implement suggestions from reviewed v1
> > > patchset.
> > > It's now a set of five patches:
> > > - linux-custom: Split up binaries from kernel headers to kbuild
> > > package
> > > - sbuild: Support overwriting configured schroot dir
> > > - dpkg: Add support for additional target and host builds
> > > - 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 fourth 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 usage of separate kbuild bitbake recipe that may enforce
> > >   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, append "target" (and "host") to ISAR_BUILDS and kbuild
> > > packages for
> > > target and host will be created automatically
> > > 
> > > Best regards
> > > 
> > > Stefan
> > > 
> > > Stefan Koch (5):
> > >   linux-custom: Split up binaries from kernel headers to kbuild
> > > package
> > >   sbuild: Support overwriting configured schroot dir
> > >   dpkg: Add support for additional target and host builds
> > >   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                          | 20 +++--
> > >  meta/classes/dpkg-base.bbclass                | 51 +++++++++++--
> > >  meta/classes/dpkg.bbclass                     |  2 +-
> > >  meta/classes/sbuild.bbclass                   |  9 ++-
> > >  .../linux/files/debian/control.tmpl           | 25 ++++++-
> > >  .../linux/files/debian/isar/build.tmpl        | 13 +++-
> > >  .../linux/files/debian/isar/common.tmpl       | 14 +++-
> > >  .../linux/files/debian/isar/configure.tmpl    | 13 +++-
> > >  .../linux/files/debian/isar/install.tmpl      | 73
> > > ++++++++++++++-----
> > >  .../linux/files/debian/rules.tmpl             |  2 +-
> > >  meta/recipes-kernel/linux/linux-custom.inc    | 51 ++++++++++---
> > >  11 files changed, 219 insertions(+), 54 deletions(-)
> > 
> > I've recently went on testing the patchset in CI.
> > 
> > - For now, on updated 'next' it at least requires some trivial
> > changes fixups 
> > caused by merged "getVar(var, True) => getVar(var)" reduction. I
> > could prepare 
> > v3 on my own or wait for new version on maillist.
> > 
> > - Also, we now have multiarch support patchset merged to `next`
> > (and that is 
> > the main reason of long non-merging this kbuild patchset). So, even
> > if the 
> > patch in its current state works, it probably could reuse new
> > approach (e.g. 
> > <package>-compat or <package>-native).
> > 
> 
> Yes, patch 1 seems likely to stay (looked good when scanned it back
> then, but I can have a closer look now), the rest needs to be
> reworked
> according to what I outlined back then. So, don't merge this series.

I have reworked the patchset to use the new multiarch support using the
-compat and -native bitbake targets.

The patchset will follow...

> 
> Jan
> 

-- 
Stefan Koch
Siemens AG
www.siemens.com