| Message ID | 20240214101025.2123540-4-stefan-koch@siemens.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
| Series | linux-custom: Split up binaries from kernel headers to kbuild package | expand |
On 14.02.24 11:10, Stefan Koch wrote: > When using a cross build this patch does introduce > target and host specific kernel kbuild packages that > ship the "scripts" and "tools" binaries. > > The "-kbuildtarget" and "-native" multiarch bitbake targets are useable to run > additional target or host specific builds for kbuild scripts and tools. > > Using the "-kbuildtarget" bitbake target enables the build of > a target specific kbuild package at cross builds. > So using "linux-kbuild" provides the package for the target platform. > > Using the "-native" bitbake target enables the build of > a host specific kbuild package at cross builds. > When cross building using "linux-kbuild-native" > provides the package for the host platform. > > Only the "host" specific package is built automatically at cross builds. > > This solves this from doc/custom_kernel.inc: > - The kernel headers package has not supported both native > and cross compilation of kernel modules when itself was cross built > - Future roadmap: Generate kernel headers package for both host > and target when using a cross build > > Signed-off-by: Stefan Koch <stefan-koch@siemens.com> This causes the kernel source packages being built twice, and the result is not even identical: ├── linux-starfive_6.6-visionfive2+r0.tar │ ├── file list │ │ @@ -28357,15 +28357,15 @@ │ │ -rw-r--r-- 0 0 0 3843 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xor.c │ │ -rw-r--r-- 0 0 0 12021 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xts.c │ │ -rw-r--r-- 0 0 0 2445 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xxhash_generic.c │ │ -rw-r--r-- 0 0 0 5090 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/zstd.c │ │ drwxr-xr-x 0 0 0 0 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/ │ │ -rw-r--r-- 0 0 0 162 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/changelog │ │ -rw-r--r-- 0 0 0 3 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/compat │ │ --rw-r--r-- 0 0 0 2694 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control │ │ +-rw-r--r-- 0 0 0 2664 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control │ │ drwxr-xr-x 0 0 0 0 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/fragments/ │ │ -rw-r--r-- 0 0 0 155 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/fragments/starfive2_extra.cfg │ │ drwxr-xr-x 0 0 0 0 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/ │ │ -rw-r--r-- 0 0 0 1875 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/build │ │ -rw-r--r-- 0 0 0 355 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/clean │ │ -rw-r--r-- 0 0 0 1830 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/common │ │ -rw-r--r-- 0 0 0 587 2023-11-21 02:56:42.000000 linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/configure │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control │ │ @@ -12,15 +12,15 @@ │ │ Description: starfive Linux kernel, version @KR@ │ │ This package contains the Linux kernel, modules and corresponding other │ │ files, version: @KR@. │ │ │ │ Package: linux-headers-starfive │ │ Build-Profiles: <kernel> │ │ Architecture: any │ │ -Depends: libc6, libssl3,, linux-kbuild-starfive:amd64 | linux-kbuild-starfive, ${perl:Depends}, ${shlib:Depends} │ │ +Depends: libc6, libssl3,, linux-kbuild-starfive, ${perl:Depends}, ${shlib:Depends} │ │ Description: starfive Linux kernel headers for @KR@ │ │ This package provides kernel header files for @KR@ on riscv64 │ │ . │ │ This is useful for people who need to build external modules │ │ │ │ Package: linux-libc-dev │ │ Build-Profiles: <!nolibcdev kernel> │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/linux-image-starfive.postinst │ │ @@ -2,15 +2,15 @@ │ │ # based on https://salsa.debian.org/kernel-team/linux/blob/479cb120ecb2b3f2c4d929a7b57860248d6f79bd/debian/templates/image.postinst.in │ │ # SPDX-License-Identifier: GPL-2.0-only │ │ │ │ # Tell initramfs builder whether it's wanted │ │ export INITRD=Yes │ │ │ │ version=@KR@ │ │ -image_path=/boot/vmlinux-${version} │ │ +image_path=/boot/vmlinuz-${version} │ │ │ │ if [ "$1" != configure ]; then │ │ exit 0 │ │ fi │ │ │ │ depmod $version │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/linux-image-starfive.postrm │ │ @@ -2,15 +2,15 @@ │ │ # based on https://salsa.debian.org/kernel-team/linux/blob/479cb120ecb2b3f2c4d929a7b57860248d6f79bd/debian/templates/image.postrm.in │ │ # SPDX-License-Identifier: GPL-2.0-only │ │ │ │ # Tell initramfs builder whether it's wanted │ │ export INITRD=Yes │ │ │ │ version=@KR@ │ │ -image_path=/boot/vmlinux-${version} │ │ +image_path=/boot/vmlinuz-${version} │ │ │ │ rm -f /lib/modules/$version/.fresh-install │ │ │ │ if [ "$1" != upgrade ] && command -v linux-update-symlinks >/dev/null; then │ │ linux-update-symlinks remove $version $image_path │ │ fi │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/linux-image-starfive.preinst │ │ @@ -2,15 +2,15 @@ │ │ # based on https://salsa.debian.org/kernel-team/linux/blob/479cb120ecb2b3f2c4d929a7b57860248d6f79bd/debian/templates/image.preinst.in │ │ # SPDX-License-Identifier: GPL-2.0-only │ │ │ │ # Tell initramfs builder whether it's wanted │ │ export INITRD=Yes │ │ │ │ version=@KR@ │ │ -image_path=/boot/vmlinux-${version} │ │ +image_path=/boot/vmlinuz-${version} │ │ │ │ if [ "$1" = abort-upgrade ]; then │ │ exit 0 │ │ fi │ │ │ │ if [ "$1" = install ]; then │ │ # Create a flag file for postinst │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/linux-image-starfive.prerm │ │ @@ -2,15 +2,15 @@ │ │ # based on https://salsa.debian.org/kernel-team/linux/blob/479cb120ecb2b3f2c4d929a7b57860248d6f79bd/debian/templates/image.prerm.in │ │ # SPDX-License-Identifier: GPL-2.0-only │ │ │ │ # Tell initramfs builder whether it's wanted │ │ export INITRD=Yes │ │ │ │ version=@KR@ │ │ -image_path=/boot/vmlinux-${version} │ │ +image_path=/boot/vmlinuz-${version} │ │ │ │ if [ "$1" != remove ]; then │ │ exit 0 │ │ fi │ │ │ │ linux-check-removal $version Running the source build twice is not just a problem of the kernel recipe (the delta surely is and should be understood as well). But the kernel package is fairly large, so this at least wastes time. And if anyone would actually pull the sources from isar-apt during the build, we had an ugly race. I have an (apparantely) working patch here that builds the sources only in the base package. Will share later. Jan
On 14.02.24 11:10, Stefan Koch wrote: > When using a cross build this patch does introduce > target and host specific kernel kbuild packages that > ship the "scripts" and "tools" binaries. > > The "-kbuildtarget" and "-native" multiarch bitbake targets are useable to run > additional target or host specific builds for kbuild scripts and tools. > > Using the "-kbuildtarget" bitbake target enables the build of > a target specific kbuild package at cross builds. > So using "linux-kbuild" provides the package for the target platform. > > Using the "-native" bitbake target enables the build of > a host specific kbuild package at cross builds. > When cross building using "linux-kbuild-native" > provides the package for the host platform. > > Only the "host" specific package is built automatically at cross builds. > > This solves this from doc/custom_kernel.inc: > - The kernel headers package has not supported both native > and cross compilation of kernel modules when itself was cross built > - Future roadmap: Generate kernel headers package for both host > and target when using a cross build > > Signed-off-by: Stefan Koch <stefan-koch@siemens.com> > --- > .../linux/classes/kbuildtarget.bbclass | 8 ++++ > .../linux/files/debian/control.tmpl | 6 ++- > .../linux/files/debian/isar/build.tmpl | 13 ++++- > .../linux/files/debian/isar/common.tmpl | 9 ++++ > .../linux/files/debian/isar/install.tmpl | 34 +++++++++----- > meta/recipes-kernel/linux/linux-custom.inc | 47 ++++++++++++++++++- > 6 files changed, 99 insertions(+), 18 deletions(-) > create mode 100644 meta/recipes-kernel/linux/classes/kbuildtarget.bbclass > > diff --git a/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass b/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass > new file mode 100644 > index 00000000..26369861 > --- /dev/null > +++ b/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass > @@ -0,0 +1,8 @@ Missing copyright header, please fix (on top). > +python kbuildtarget_virtclass_handler() { > + pn = e.data.getVar('PN') > + if pn.endswith('-kbuildtarget'): > + e.data.setVar('BPN', pn[:-len('-kbuildtarget')]) > + e.data.appendVar('OVERRIDES', ':class-kbuildtarget') > +} > +addhandler kbuildtarget_virtclass_handler > +kbuildtarget_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise" Some newline separators would help with the readability - when at it, please fix this as well. Finally, I'm still trying to understand while the -native recipe is built even in the absence of a kernel module which would need it. This seems broken. Jan
On Sun, 2024-05-05 at 19:16 +0200, Jan Kiszka wrote: > On 14.02.24 11:10, Stefan Koch wrote: > > When using a cross build this patch does introduce > > target and host specific kernel kbuild packages that > > ship the "scripts" and "tools" binaries. > > > > The "-kbuildtarget" and "-native" multiarch bitbake targets are > > useable to run > > additional target or host specific builds for kbuild scripts and > > tools. > > > > Using the "-kbuildtarget" bitbake target enables the build of > > a target specific kbuild package at cross builds. > > So using "linux-kbuild" provides the package for the target > > platform. > > > > Using the "-native" bitbake target enables the build of > > a host specific kbuild package at cross builds. > > When cross building using "linux-kbuild-native" > > provides the package for the host platform. > > > > Only the "host" specific package is built automatically at cross > > builds. > > > > This solves this from doc/custom_kernel.inc: > > - The kernel headers package has not supported both native > > and cross compilation of kernel modules when itself was cross > > built > > - Future roadmap: Generate kernel headers package for both host > > and target when using a cross build > > > > Signed-off-by: Stefan Koch <stefan-koch@siemens.com> > > This causes the kernel source packages being built twice, and the > result > is not even identical: > > ├── linux-starfive_6.6-visionfive2+r0.tar > │ ├── file list > │ │ @@ -28357,15 +28357,15 @@ > │ │ -rw-r--r-- 0 0 0 3843 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xor.c > │ │ -rw-r--r-- 0 0 0 12021 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xts.c > │ │ -rw-r--r-- 0 0 0 2445 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xxhash_generic.c > │ │ -rw-r--r-- 0 0 0 5090 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/zstd.c > │ │ drwxr-xr-x 0 0 0 0 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/ > │ │ -rw-r--r-- 0 0 0 162 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/changelog > │ │ -rw-r--r-- 0 0 0 3 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/compat > │ │ --rw-r--r-- 0 0 0 2694 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control > │ │ +-rw-r--r-- 0 0 0 2664 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control > │ │ drwxr-xr-x 0 0 0 0 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/fragments/ > │ │ -rw-r--r-- 0 0 0 155 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/fragments/starfive2_e > xtra.cfg > │ │ drwxr-xr-x 0 0 0 0 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/ > │ │ -rw-r--r-- 0 0 0 1875 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/build > │ │ -rw-r--r-- 0 0 0 355 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/clean > │ │ -rw-r--r-- 0 0 0 1830 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/common > │ │ -rw-r--r-- 0 0 0 587 2023-11-21 > 02:56:42.000000 linux- > 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/configure > │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control > │ │ @@ -12,15 +12,15 @@ > │ │ Description: starfive Linux kernel, version @KR@ > │ │ This package contains the Linux kernel, modules and > corresponding other > │ │ files, version: @KR@. > │ │ > │ │ Package: linux-headers-starfive > │ │ Build-Profiles: <kernel> > │ │ Architecture: any > │ │ -Depends: libc6, libssl3,, > linux-kbuild-starfive:amd64 | linux-kbuild-starfive, ${perl:Depends}, > ${shlib:Depends} > │ │ +Depends: libc6, libssl3,, This comes from here: meta/recipes-kernel/linux/linux-custom.inc:114-115 # Select correct kbuild package for isar cross-build HEADERS_DEPENDS:cross-profile = ", linux-kbuild- ${KERNEL_NAME_PROVIDED}:${HOST_ARCH} | linux-kbuild- ${KERNEL_NAME_PROVIDED}" > linux-kbuild-starfive, ${perl:Depends}, ${shlib:Depends} > │ │ Description: starfive Linux kernel headers for @KR@ > │ │ This package provides kernel header files for @KR@ on riscv64 > │ │ . > │ │ This is useful for people who need to build external modules > │ │ > │ │ Package: linux-libc-dev > │ │ Build-Profiles: <!nolibcdev kernel> > │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/linux- > image-starfive.postinst > │ │ @@ -2,15 +2,15 @@ > │ │ # based on > https://salsa.debian.org/kernel-team/linux/blob/479cb120ecb2b3f2c4d929a7b57860248d6f79bd/debian/templates/image.postinst.in > │ │ # SPDX-License-Identifier: GPL-2.0-only > │ │ > │ │ # Tell initramfs builder whether it's wanted > │ │ export INITRD=Yes > │ │ > │ │ version=@KR@ > │ │ -image_path=/boot/vmlinux-${version} > │ │ +image_path=/boot/vmlinuz-${version} This comes from here: meta/recipes-kernel/linux/files/debian/isar/install.tmpl:25-29 case "${ARCH}" in mips|powerpc|riscv|arm64) kimage_path="boot/vmlinux-${krel}" ;; um) kimage_path="usr/bin/vmlinux-${krel}" ;; *) kimage_path="boot/vmlinuz-${krel}" ;; esac > │ │ > │ │ if [ "$1" != configure ]; then > │ │ exit 0 > │ │ fi > │ │ > │ │ depmod $version > │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/linux- > image-starfive.postrm > │ │ @@ -2,15 +2,15 @@ > │ │ # based on > https://salsa.debian.org/kernel-team/linux/blob/479cb120ecb2b3f2c4d929a7b57860248d6f79bd/debian/templates/image.postrm.in > │ │ # SPDX-License-Identifier: GPL-2.0-only > │ │ > │ │ # Tell initramfs builder whether it's wanted > │ │ export INITRD=Yes > │ │ > │ │ version=@KR@ > │ │ -image_path=/boot/vmlinux-${version} > │ │ +image_path=/boot/vmlinuz-${version} > │ │ > │ │ rm -f /lib/modules/$version/.fresh-install > │ │ > │ │ if [ "$1" != upgrade ] && command -v linux-update-symlinks > >/dev/null; then > │ │ linux-update-symlinks remove $version $image_path > │ │ fi > │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/linux- > image-starfive.preinst > │ │ @@ -2,15 +2,15 @@ > │ │ # based on > https://salsa.debian.org/kernel-team/linux/blob/479cb120ecb2b3f2c4d929a7b57860248d6f79bd/debian/templates/image.preinst.in > │ │ # SPDX-License-Identifier: GPL-2.0-only > │ │ > │ │ # Tell initramfs builder whether it's wanted > │ │ export INITRD=Yes > │ │ > │ │ version=@KR@ > │ │ -image_path=/boot/vmlinux-${version} > │ │ +image_path=/boot/vmlinuz-${version} > │ │ > │ │ if [ "$1" = abort-upgrade ]; then > │ │ exit 0 > │ │ fi > │ │ > │ │ if [ "$1" = install ]; then > │ │ # Create a flag file for postinst > │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/linux- > image-starfive.prerm > │ │ @@ -2,15 +2,15 @@ > │ │ # based on > https://salsa.debian.org/kernel-team/linux/blob/479cb120ecb2b3f2c4d929a7b57860248d6f79bd/debian/templates/image.prerm.in > │ │ # SPDX-License-Identifier: GPL-2.0-only > │ │ > │ │ # Tell initramfs builder whether it's wanted > │ │ export INITRD=Yes > │ │ > │ │ version=@KR@ > │ │ -image_path=/boot/vmlinux-${version} > │ │ +image_path=/boot/vmlinuz-${version} > │ │ > │ │ if [ "$1" != remove ]; then > │ │ exit 0 > │ │ fi > │ │ > │ │ linux-check-removal $version > > > Running the source build twice is not just a problem of the kernel > recipe (the delta surely is and should be understood as well). See beyond for hints about the delta > But the > kernel package is fairly large, so this at least wastes time. And if > anyone would actually pull the sources from isar-apt during the > build, > we had an ugly race. > > I have an (apparantely) working patch here that builds the sources > only > in the base package. Will share later. > > Jan > -- Stefan Koch Siemens AG http://www.siemens.com/
On 06.05.24 12:07, Koch, Stefan (DI PA DCP R&D 3) wrote: > On Sun, 2024-05-05 at 19:16 +0200, Jan Kiszka wrote: >> On 14.02.24 11:10, Stefan Koch wrote: >>> When using a cross build this patch does introduce >>> target and host specific kernel kbuild packages that >>> ship the "scripts" and "tools" binaries. >>> >>> The "-kbuildtarget" and "-native" multiarch bitbake targets are >>> useable to run >>> additional target or host specific builds for kbuild scripts and >>> tools. >>> >>> Using the "-kbuildtarget" bitbake target enables the build of >>> a target specific kbuild package at cross builds. >>> So using "linux-kbuild" provides the package for the target >>> platform. >>> >>> Using the "-native" bitbake target enables the build of >>> a host specific kbuild package at cross builds. >>> When cross building using "linux-kbuild-native" >>> provides the package for the host platform. >>> >>> Only the "host" specific package is built automatically at cross >>> builds. >>> >>> This solves this from doc/custom_kernel.inc: >>> - The kernel headers package has not supported both native >>> and cross compilation of kernel modules when itself was cross >>> built >>> - Future roadmap: Generate kernel headers package for both host >>> and target when using a cross build >>> >>> Signed-off-by: Stefan Koch <stefan-koch@siemens.com> >> >> This causes the kernel source packages being built twice, and the >> result >> is not even identical: >> >> ├── linux-starfive_6.6-visionfive2+r0.tar >> │ ├── file list >> │ │ @@ -28357,15 +28357,15 @@ >> │ │ -rw-r--r-- 0 0 0 3843 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xor.c >> │ │ -rw-r--r-- 0 0 0 12021 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xts.c >> │ │ -rw-r--r-- 0 0 0 2445 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xxhash_generic.c >> │ │ -rw-r--r-- 0 0 0 5090 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/zstd.c >> │ │ drwxr-xr-x 0 0 0 0 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/ >> │ │ -rw-r--r-- 0 0 0 162 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/changelog >> │ │ -rw-r--r-- 0 0 0 3 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/compat >> │ │ --rw-r--r-- 0 0 0 2694 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control >> │ │ +-rw-r--r-- 0 0 0 2664 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control >> │ │ drwxr-xr-x 0 0 0 0 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/fragments/ >> │ │ -rw-r--r-- 0 0 0 155 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/fragments/starfive2_e >> xtra.cfg >> │ │ drwxr-xr-x 0 0 0 0 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/ >> │ │ -rw-r--r-- 0 0 0 1875 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/build >> │ │ -rw-r--r-- 0 0 0 355 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/clean >> │ │ -rw-r--r-- 0 0 0 1830 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/common >> │ │ -rw-r--r-- 0 0 0 587 2023-11-21 >> 02:56:42.000000 linux- >> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/configure >> │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control >> │ │ @@ -12,15 +12,15 @@ >> │ │ Description: starfive Linux kernel, version @KR@ >> │ │ This package contains the Linux kernel, modules and >> corresponding other >> │ │ files, version: @KR@. >> │ │ >> │ │ Package: linux-headers-starfive >> │ │ Build-Profiles: <kernel> >> │ │ Architecture: any >> │ │ -Depends: libc6, libssl3,, >> linux-kbuild-starfive:amd64 | linux-kbuild-starfive, ${perl:Depends}, >> ${shlib:Depends} >> │ │ +Depends: libc6, libssl3,, > This comes from here: > meta/recipes-kernel/linux/linux-custom.inc:114-115 > > # Select correct kbuild package for isar cross-build > HEADERS_DEPENDS:cross-profile = ", linux-kbuild- > ${KERNEL_NAME_PROVIDED}:${HOST_ARCH} | linux-kbuild- > ${KERNEL_NAME_PROVIDED}" Should be become unconditional. But I'm not even sure about that HOST_ARCH in it. That is normally not decided at control file level. >> linux-kbuild-starfive, ${perl:Depends}, ${shlib:Depends} >> │ │ Description: starfive Linux kernel headers for @KR@ >> │ │ This package provides kernel header files for @KR@ on riscv64 >> │ │ . >> │ │ This is useful for people who need to build external modules >> │ │ >> │ │ Package: linux-libc-dev >> │ │ Build-Profiles: <!nolibcdev kernel> >> │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/linux- >> image-starfive.postinst >> │ │ @@ -2,15 +2,15 @@ >> │ │ # based on >> https://salsa.debian.org/kernel-team/linux/blob/479cb120ecb2b3f2c4d929a7b57860248d6f79bd/debian/templates/image.postinst.in >> │ │ # SPDX-License-Identifier: GPL-2.0-only >> │ │ >> │ │ # Tell initramfs builder whether it's wanted >> │ │ export INITRD=Yes >> │ │ >> │ │ version=@KR@ >> │ │ -image_path=/boot/vmlinux-${version} >> │ │ +image_path=/boot/vmlinuz-${version} > This comes from here: > meta/recipes-kernel/linux/files/debian/isar/install.tmpl:25-29 > > case "${ARCH}" in > mips|powerpc|riscv|arm64) kimage_path="boot/vmlinux-${krel}" ;; > um) kimage_path="usr/bin/vmlinux-${krel}" ;; > *) kimage_path="boot/vmlinuz-${krel}" ;; ...and the fact that ARCH is not properly set across all build variants. Was harmless so far, but better fix to avoid future surprises. Jan
14/02/2024 12:10, 'Stefan Koch' via isar-users wrote: > When using a cross build this patch does introduce > target and host specific kernel kbuild packages that > ship the "scripts" and "tools" binaries. > > The "-kbuildtarget" and "-native" multiarch bitbake targets are useable to run > additional target or host specific builds for kbuild scripts and tools. > > Using the "-kbuildtarget" bitbake target enables the build of > a target specific kbuild package at cross builds. > So using "linux-kbuild" provides the package for the target platform. > > Using the "-native" bitbake target enables the build of > a host specific kbuild package at cross builds. > When cross building using "linux-kbuild-native" > provides the package for the host platform. > > Only the "host" specific package is built automatically at cross builds. > > This solves this from doc/custom_kernel.inc: > - The kernel headers package has not supported both native > and cross compilation of kernel modules when itself was cross built > - Future roadmap: Generate kernel headers package for both host > and target when using a cross build > > Signed-off-by: Stefan Koch <stefan-koch@siemens.com> Hello Stefan, The changes from this patch probably cause wrong asm headers placing: https://github.com/ilbers/isar/issues/105 Can you please take a look?
On Thu, 2024-07-04 at 09:12 +0300, Anton Mikanovich wrote: > 14/02/2024 12:10, 'Stefan Koch' via isar-users wrote: > > When using a cross build this patch does introduce > > target and host specific kernel kbuild packages that > > ship the "scripts" and "tools" binaries. > > > > The "-kbuildtarget" and "-native" multiarch bitbake targets are > > useable to run > > additional target or host specific builds for kbuild scripts and > > tools. > > > > Using the "-kbuildtarget" bitbake target enables the build of > > a target specific kbuild package at cross builds. > > So using "linux-kbuild" provides the package for the target > > platform. > > > > Using the "-native" bitbake target enables the build of > > a host specific kbuild package at cross builds. > > When cross building using "linux-kbuild-native" > > provides the package for the host platform. > > > > Only the "host" specific package is built automatically at cross > > builds. > > > > This solves this from doc/custom_kernel.inc: > > - The kernel headers package has not supported both native > > and cross compilation of kernel modules when itself was cross > > built > > - Future roadmap: Generate kernel headers package for both host > > and target when using a cross build > > > > Signed-off-by: Stefan Koch <stefan-koch@siemens.com> > > Hello Stefan, > > The changes from this patch probably cause wrong asm headers placing: > > https://github.com/ilbers/isar/issues/105 > > Can you please take a look? Thanks. I have created two patches. I'll send these to the list. KERNEL_LIBC_DEV_DEPLOY must set manually to 1 otherwise build is skipped and linux-libc-dev binary package from debian is used. > -- Stefan Koch Siemens AG http://www.siemens.com/
> ________________________________________ > From: Koch, Stefan (DI PA DCP R&D 3) <stefan-koch@siemens.com> > Sent: Thursday, July 4, 2024 2:44 PM > To: amikan@ilbers.de <amikan@ilbers.de>; isar-users@googlegroups.com <isar-users@googlegroups.com> > Cc: Storm, Christian (T CED OES-DE) <christian.storm@siemens.com>; ibr@ilbers.de <ibr@ilbers.de>; Hombourger, Cedric (DI CTO FDS CES LX) > <cedric.hombourger@siemens.com>; Adler, Michael (T CED OES-DE) <michael.adler@siemens.com>; Sudler, Simon (DI PA DCP TI) <simon.sudler@siemens.com>; Moessbauer, Felix (T CED OES-DE) <felix.moessbauer@siemens.com>; Schmidt, Adriaan (T CED EDC-DE) <adriaan.schmidt@siemens.com>; Kiszka, Jan (T CED) <jan.kiszka@siemens.com>; ubely@ilbers.de <ubely@ilbers.de> > Subject: Re: [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages > > On Thu, 2024-07-04 at 09:12 +0300, Anton Mikanovich wrote: > > 14/02/2024 12:10, 'Stefan Koch' via isar-users wrote: > > > When using a cross build this patch does introduce > > > target and host specific kernel kbuild packages that > > > ship the "scripts" and "tools" binaries. > > > > > > The "-kbuildtarget" and "-native" multiarch bitbake targets are > > > useable to run > > > additional target or host specific builds for kbuild scripts and > > > tools. > > > > > > Using the "-kbuildtarget" bitbake target enables the build of > > > a target specific kbuild package at cross builds. > > > So using "linux-kbuild" provides the package for the target > > > platform. > > > > > > Using the "-native" bitbake target enables the build of > > > a host specific kbuild package at cross builds. > > > When cross building using "linux-kbuild-native" > > > provides the package for the host platform. > > > > > > Only the "host" specific package is built automatically at cross > > > builds. > > > > > > This solves this from doc/custom_kernel.inc: > > > - The kernel headers package has not supported both native > > > and cross compilation of kernel modules when itself was cross > > > built > > > - Future roadmap: Generate kernel headers package for both host > > > and target when using a cross build > > > > > > Signed-off-by: Stefan Koch <stefan-koch@siemens.com> > > > Hello Stefan, > > > > The changes from this patch probably cause wrong asm headers placing: > > > > https://github.com/ilbers/isar/issues/105 > > > > Can you please take a look? > Thanks. I have created two patches. I'll send these to the list. > KERNEL_LIBC_DEV_DEPLOY must set manually to 1 otherwise build is > skipped and linux-libc-dev binary package from debian is used. Should we switch to always generate this package but with a suffix (-${KERNEL_NAME}) and add the following to its package spec: Provides: linux-libc-dev Replaces: linux-libc-dev Conflicts: linux-libc-dev I have been recently experimenting with this change. This allows both Debian's linux-libc-dev and a custom linux-libc-dev package to co-exist in a package repository. People wanting their custom linux-libc-headers in the sbuild environment (e.g. because they have a driver shipping custom headers with additional ioctls defined) to get them installed there. I am happy to send a PATCH if people are OK with the approach. That patch would let us mark KERNEL_LIBC_DEV_DEPLOY as deprecated and eventually remove it in a not too distant future Cedric
On Thu, 2024-07-04 at 13:02 +0000, Hombourger, Cedric (DI CTO FDS CES LX) wrote: > > > > ________________________________________ > > From: Koch, Stefan (DI PA DCP R&D 3) <stefan-koch@siemens.com> > > Sent: Thursday, July 4, 2024 2:44 PM > > To: amikan@ilbers.de <amikan@ilbers.de>; > > isar-users@googlegroups.com <isar-users@googlegroups.com> > > Cc: Storm, Christian (T CED OES-DE) <christian.storm@siemens.com>; > > ibr@ilbers.de <ibr@ilbers.de>; Hombourger, Cedric (DI CTO FDS CES > > LX) > <cedric.hombourger@siemens.com>; Adler, Michael (T CED OES- > > DE) <michael.adler@siemens.com>; Sudler, Simon (DI PA DCP TI) > > <simon.sudler@siemens.com>; Moessbauer, Felix (T CED OES-DE) > > <felix.moessbauer@siemens.com>; Schmidt, Adriaan (T CED EDC-DE) > > <adriaan.schmidt@siemens.com>; Kiszka, Jan (T CED) > > <jan.kiszka@siemens.com>; ubely@ilbers.de <ubely@ilbers.de> > > Subject: Re: [PATCH v6 3/5] linux-custom: Provide target and host > > specific kernel kbuild packages > > > > On Thu, 2024-07-04 at 09:12 +0300, Anton Mikanovich wrote: > > > 14/02/2024 12:10, 'Stefan Koch' via isar-users wrote: > > > > When using a cross build this patch does introduce > > > > target and host specific kernel kbuild packages that > > > > ship the "scripts" and "tools" binaries. > > > > > > > > The "-kbuildtarget" and "-native" multiarch bitbake targets are > > > > useable to run > > > > additional target or host specific builds for kbuild scripts > > > > and > > > > tools. > > > > > > > > Using the "-kbuildtarget" bitbake target enables the build of > > > > a target specific kbuild package at cross builds. > > > > So using "linux-kbuild" provides the package for the target > > > > platform. > > > > > > > > Using the "-native" bitbake target enables the build of > > > > a host specific kbuild package at cross builds. > > > > When cross building using "linux-kbuild-native" > > > > provides the package for the host platform. > > > > > > > > Only the "host" specific package is built automatically at > > > > cross > > > > builds. > > > > > > > > This solves this from doc/custom_kernel.inc: > > > > - The kernel headers package has not supported both native > > > > and cross compilation of kernel modules when itself was > > > > cross > > > > built > > > > - Future roadmap: Generate kernel headers package for both host > > > > and target when using a cross build > > > > > > > > Signed-off-by: Stefan Koch <stefan-koch@siemens.com> > > > > > Hello Stefan, > > > > > > The changes from this patch probably cause wrong asm headers > > > placing: > > > > > > https://github.com/ilbers/isar/issues/105 > > > > > > Can you please take a look? > > Thanks. I have created two patches. I'll send these to the list. > > KERNEL_LIBC_DEV_DEPLOY must set manually to 1 otherwise build is > > skipped and linux-libc-dev binary package from debian is used. Sent both to the list... > > Should we switch to always generate this package but with a suffix (- > ${KERNEL_NAME}) and add the following to its package spec: > Provides: linux-libc-dev > Replaces: linux-libc-dev > Conflicts: linux-libc-dev > > I have been recently experimenting with this change. This allows both > Debian's linux-libc-dev and a custom linux-libc-dev package to co- > exist in a package repository. People wanting their custom linux- > libc-headers in the sbuild environment (e.g. because they have a > driver shipping custom headers with additional ioctls defined) to get > them installed there. Seems to be make sense. Might be renaming from: linux-libc-dev linux-libc-dev-${DISTRO_ARCH}-cross to: linux-libc-dev-${KERNEL_NAME_PROVIDED} linux-libc-dev-${KERNEL_NAME_PROVIDED}-${DISTRO_ARCH}-cross > > I am happy to send a PATCH if people are OK with the approach. That > patch would let us mark KERNEL_LIBC_DEV_DEPLOY as deprecated and > eventually remove it in a not too distant future Will you include that change above, too? > > Cedric -- Stefan Koch Siemens AG http://www.siemens.com/
diff --git a/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass b/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass new file mode 100644 index 00000000..26369861 --- /dev/null +++ b/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass @@ -0,0 +1,8 @@ +python kbuildtarget_virtclass_handler() { + pn = e.data.getVar('PN') + if pn.endswith('-kbuildtarget'): + e.data.setVar('BPN', pn[:-len('-kbuildtarget')]) + e.data.appendVar('OVERRIDES', ':class-kbuildtarget') +} +addhandler kbuildtarget_virtclass_handler +kbuildtarget_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise" diff --git a/meta/recipes-kernel/linux/files/debian/control.tmpl b/meta/recipes-kernel/linux/files/debian/control.tmpl index 7f271367..6f8f8afe 100644 --- a/meta/recipes-kernel/linux/files/debian/control.tmpl +++ b/meta/recipes-kernel/linux/files/debian/control.tmpl @@ -6,6 +6,7 @@ Build-Depends: bc, kmod, cpio, ${KBUILD_DEPENDS} Homepage: http://www.kernel.org/ Package: linux-image-${KERNEL_NAME_PROVIDED} +Build-Profiles: <kernel> Architecture: any Depends: ${KERNEL_DEBIAN_DEPENDS} Description: ${KERNEL_NAME_PROVIDED} Linux kernel, version @KR@ @@ -13,6 +14,7 @@ Description: ${KERNEL_NAME_PROVIDED} Linux kernel, version @KR@ files, version: @KR@. Package: linux-headers-${KERNEL_NAME_PROVIDED} +Build-Profiles: <kernel> Architecture: any Depends: ${KERNEL_HEADERS_DEBIAN_DEPENDS}, ${perl:Depends}, ${shlib:Depends} Description: ${KERNEL_NAME_PROVIDED} Linux kernel headers for @KR@ @@ -21,7 +23,7 @@ Description: ${KERNEL_NAME_PROVIDED} Linux kernel headers for @KR@ This is useful for people who need to build external modules Package: linux-libc-dev -Build-Profiles: <!nolibcdev> +Build-Profiles: <!nolibcdev kernel> Section: devel Provides: linux-kernel-headers Architecture: any @@ -41,6 +43,7 @@ Description: Linux Kernel Headers for development (for cross-compiling) your kernel. Use linux-headers-* packages for that. Package: linux-image-${KERNEL_NAME_PROVIDED}-dbg +Build-Profiles: <kernel> Section: debug Architecture: any Description: Linux kernel debugging symbols for @KR@ @@ -48,6 +51,7 @@ Description: Linux kernel debugging symbols for @KR@ all the necessary debug symbols for the kernel and its modules. Package: linux-kbuild-${KERNEL_NAME_PROVIDED} +Build-Profiles: <kbuild> Architecture: any Depends: ${perl:Depends}, ${shlib:Depends} Description: ${KERNEL_NAME_PROVIDED} Linux kbuild scripts and tools for @KR@ diff --git a/meta/recipes-kernel/linux/files/debian/isar/build.tmpl b/meta/recipes-kernel/linux/files/debian/isar/build.tmpl index 906dc580..81a6ba8a 100644 --- a/meta/recipes-kernel/linux/files/debian/isar/build.tmpl +++ b/meta/recipes-kernel/linux/files/debian/isar/build.tmpl @@ -21,8 +21,17 @@ do_build() { KR=$(${MAKE} O=${KERNEL_BUILD_DIR} -s --no-print-directory kernelrelease) sed -i "s/@KR@/${KR}/g" ${S}/debian/control ${S}/debian/linux-image-${KERNEL_NAME_PROVIDED}.* - # Build the Linux kernel - ${MAKE} O=${KERNEL_BUILD_DIR} ${PARALLEL_MAKE} KCFLAGS="${KCFLAGS}" KAFLAGS="${KAFLAGS}" + if echo "${DEB_BUILD_PROFILES}" | grep -q "kernel"; then # Build kernel scripts and tools + ${MAKE} O=${KERNEL_BUILD_DIR} ${PARALLEL_MAKE} KCFLAGS="${KCFLAGS}" KAFLAGS="${KAFLAGS}" + elif echo "${DEB_BUILD_PROFILES}" | grep -q "kbuild"; then # Build kernel scripts and tools + ${MAKE} O=${KERNEL_BUILD_DIR} ${PARALLEL_MAKE} KCFLAGS="${KCFLAGS}" KAFLAGS="${KAFLAGS}" scripts + if grep -q -E "CONFIG_STACK_VALIDATION=y|CONFIG_HAVE_OBJTOOL=y" ${KERNEL_BUILD_DIR}/.config && [ -d "tools/objtool" ]; then + ${MAKE} O=${KERNEL_BUILD_DIR} ${PARALLEL_MAKE} KCFLAGS="${KCFLAGS}" KAFLAGS="${KAFLAGS}" tools/objtool || true + fi + if grep -q "CONFIG_MODULES=y" ${KERNEL_BUILD_DIR}/.config; then + ${MAKE} O=${KERNEL_BUILD_DIR} ${PARALLEL_MAKE} KCFLAGS="${KCFLAGS}" KAFLAGS="${KAFLAGS}" modules_prepare + fi + fi # Stop tracing set +x diff --git a/meta/recipes-kernel/linux/files/debian/isar/common.tmpl b/meta/recipes-kernel/linux/files/debian/isar/common.tmpl index 0944e943..e3a1d8a0 100644 --- a/meta/recipes-kernel/linux/files/debian/isar/common.tmpl +++ b/meta/recipes-kernel/linux/files/debian/isar/common.tmpl @@ -12,6 +12,15 @@ KERNEL_PKG_LIBC_HEADERS=linux-libc-dev KERNEL_PKG_LIBC_HEADERS_CROSS=linux-libc-dev-${DISTRO_ARCH}-cross KERNEL_PKG_KERN_KBUILD=linux-kbuild-${KERNEL_NAME_PROVIDED} +# Force creating debian package with valid host arch for -native build +# Use a cross build to comply with arch specific kernel defconfigs +# The scripts and tools are always created for host arch +if echo "${DEB_BUILD_PROFILES}" | grep -q -e "cross" -e "kbuild" +then + eval $(dpkg-architecture -f -A ${DISTRO_ARCH}) + CROSS_COMPILE=${DEB_TARGET_GNU_TYPE}- +fi + # Constants KCONF=.config diff --git a/meta/recipes-kernel/linux/files/debian/isar/install.tmpl b/meta/recipes-kernel/linux/files/debian/isar/install.tmpl index 97780dcc..77856aee 100644 --- a/meta/recipes-kernel/linux/files/debian/isar/install.tmpl +++ b/meta/recipes-kernel/linux/files/debian/isar/install.tmpl @@ -33,20 +33,28 @@ do_install() { # Trace what we do here set -x - # Run the install steps - install_image - if [ "${ARCH}" != "um" ]; then - install_config - install_map + if echo "${DEB_BUILD_PROFILES}" | grep -q "kbuild"; then + # Install kernel scripts and tools + install_kbuild ${deb_kern_kbuild_dir} + fi + + if echo "${DEB_BUILD_PROFILES}" | grep -q "kernel"; then + if echo "${DEB_BUILD_PROFILES}" | grep -q "cross"; then + # Install cross kernel scripts and tools + install_kbuild ${deb_kern_kbuild_dir}-${HOST_ARCH}-cross + fi + + # Run the install steps + install_image + if [ "${ARCH}" != "um" ]; then + install_config + install_map + fi + install_hooks + install_dtbs + install_kmods + install_headers fi - install_hooks - install_dtbs - install_kmods - install_headers - - # Cleanup and install kernel scripts and tools - rm -rf ${deb_kern_kbuild_dir} - install_kbuild ${deb_kern_kbuild_dir} # Stop tracing set +x diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc index cbd23dc2..9c52751c 100644 --- a/meta/recipes-kernel/linux/linux-custom.inc +++ b/meta/recipes-kernel/linux/linux-custom.inc @@ -86,28 +86,71 @@ TEMPLATE_VARS += " \ inherit dpkg inherit template +inherit kbuildtarget # Add custom cflags to the kernel build KCFLAGS ?= "-fdebug-prefix-map=${CURDIR}=." KAFLAGS ?= "-fdebug-prefix-map=${CURDIR}=." # Derive name of the kernel packages from the name of this recipe -KERNEL_NAME_PROVIDED ?= "${@ d.getVar('PN').partition('linux-')[2]}" +KERNEL_NAME_PROVIDED ?= "${@ d.getVar('BPN').partition('linux-')[2]}" + +# Determine cross-profile override +python() { + if d.getVar("DISTRO_ARCH") != d.getVar("HOST_ARCH") and d.getVar("ISAR_CROSS_COMPILE", True) == "1" and "class-native" not in d.getVar("OVERRIDES", True).split(":"): + d.appendVar("OVERRIDES", ":cross-profile") +} + +# Default profiles and provides +BUILD_PROFILES = "kernel kbuild" + +# We only offer the -kbuildtarget variant when actually cross compiling +BBCLASSEXTEND:append:cross-profile = " kbuildtarget" + +# When cross-profile is active: +# build only kernel with the default variant of the recipe +BUILD_PROFILES:cross-profile = "kernel" + +# Select correct kbuild package for isar cross-build +HEADERS_DEPENDS:cross-profile = ", linux-kbuild-${KERNEL_NAME_PROVIDED}:${HOST_ARCH} | linux-kbuild-${KERNEL_NAME_PROVIDED}" + +# -native: kbuild package for host +BUILD_PROFILES:class-native = "kbuild" +RECIPE_PROVIDES:class-native = "linux-kbuild-${KERNEL_NAME_PROVIDED}-native" + +# -kbuildtarget: kbuild package for target, enforcing non-cross-build +BUILD_PROFILES:class-kbuildtarget = "kbuild" +RECIPE_PROVIDES:class-kbuildtarget = "linux-kbuild-${KERNEL_NAME_PROVIDED}" +ISAR_CROSS_COMPILE:class-kbuildtarget = "0" # Make bitbake know we will be producing linux-image and linux-headers packages # Also make it know about other packages from control -PROVIDES += " \ +RECIPE_PROVIDES = " \ linux-image-${KERNEL_NAME_PROVIDED} \ linux-headers-${KERNEL_NAME_PROVIDED} \ linux-libc-dev \ linux-libc-dev-${DISTRO_ARCH}-cross \ linux-image-${KERNEL_NAME_PROVIDED}-dbg \ + linux-kbuild-${KERNEL_NAME_PROVIDED} \ " +# When cross-profile is active: +# kbuild package is provided by -native or -kbuildtarget variant +# Otherwise it's provided by the default variant +RECIPE_PROVIDES:remove:cross-profile = "linux-kbuild-${KERNEL_NAME_PROVIDED}" # Append headers depends HEADERS_DEPENDS = ", linux-kbuild-${KERNEL_NAME_PROVIDED}" KERNEL_HEADERS_DEBIAN_DEPENDS:append = "${HEADERS_DEPENDS}" +# Append provides +PROVIDES += "${RECIPE_PROVIDES}" + +# Append build profiles +DEB_BUILD_PROFILES += "${BUILD_PROFILES}" + +# Add dependency to build -kbuildtarget and -native automatically +RDEPENDS:append:cross-profile = " ${BPN}-native" + def get_kernel_arch(d): distro_arch = d.getVar("DISTRO_ARCH") if distro_arch in ["amd64", "i386"]:
When using a cross build this patch does introduce target and host specific kernel kbuild packages that ship the "scripts" and "tools" binaries. The "-kbuildtarget" and "-native" multiarch bitbake targets are useable to run additional target or host specific builds for kbuild scripts and tools. Using the "-kbuildtarget" bitbake target enables the build of a target specific kbuild package at cross builds. So using "linux-kbuild" provides the package for the target platform. Using the "-native" bitbake target enables the build of a host specific kbuild package at cross builds. When cross building using "linux-kbuild-native" provides the package for the host platform. Only the "host" specific package is built automatically at cross builds. This solves this from doc/custom_kernel.inc: - The kernel headers package has not supported both native and cross compilation of kernel modules when itself was cross built - Future roadmap: Generate kernel headers package for both host and target when using a cross build Signed-off-by: Stefan Koch <stefan-koch@siemens.com> --- .../linux/classes/kbuildtarget.bbclass | 8 ++++ .../linux/files/debian/control.tmpl | 6 ++- .../linux/files/debian/isar/build.tmpl | 13 ++++- .../linux/files/debian/isar/common.tmpl | 9 ++++ .../linux/files/debian/isar/install.tmpl | 34 +++++++++----- meta/recipes-kernel/linux/linux-custom.inc | 47 ++++++++++++++++++- 6 files changed, 99 insertions(+), 18 deletions(-) create mode 100644 meta/recipes-kernel/linux/classes/kbuildtarget.bbclass