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

[Jan Kiszka <jan.kiszka@siemens.com>]

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.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux