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

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

On Tue, 2023-09-05 at 22:17 +0200, 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
> 
> Most things look fairly good, however - maybe it's just too late
> today -
> I'm not yet getting the scenario where -compat plays a role. My
> impression is right now, you are misusing this for some scenario it
> is
> not designed for (compat = 32-bit package for 64-bit target). Or am I
> misinterpreting this?

Yes, compat is used for the target build. See last answer for [PATCH v4
2/3].

> 
> Jan
> 

-- 
Stefan Koch
Siemens AG
www.siemens.com