Message ID | 20221220170921.1718503-1-stefan-koch@siemens.com |
---|---|
Headers | show |
Series | linux-custom: Split up binaries from kernel headers to kbuild packages | expand |
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).
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 >