[PATCH v5 0/4] linux-custom: Split up binaries from kernel headers to kbuild package

[PATCH v5 0/4] linux-custom: Split up binaries from kernel headers to kbuild package

[Stefan Koch]

Hi

This updated v5 patchset implement suggestions from reviewed v4 patchset.
It's now a set of four patches:
- linux-custom: Set PROVIDES variable using bitbake overrides
- linux-custom: Split up binaries from kernel headers to kbuild package
- linux-custom: Provide target and host specific kernel kbuild packages
- docs: Update custom_kernel docs for split up of kernel scripts and tools

The first commit sets the PROVIDES variable using
bitbake overrides instead of python code.

Swap out the binaries from the kernel headers
into kernel kbuild package is the main use-case
introduced by the second commit
"Split up binaries from kernel headers to kbuild package"

The third commit "Provide target and host specific kernel kbuild packages"
introduces that the binaries could be swapped out into host and target
specific kernel kbuild packages.

These are the main development goals:

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, and use the new linux-kbuild bitbake target
  to create the kbuild target package when cross building

Best regards

Stefan

Stefan Koch (4):
  linux-custom: Set PROVIDES variable using bitbake overrides
  linux-custom: Split up binaries from kernel headers to kbuild package
  linux-custom: Provide target and host specific kernel kbuild packages
  docs: Update custom_kernel docs for split up of kernel scripts and
    tools

 doc/custom_kernel.md                          | 18 +++--
 .../linux/classes/kbuildtarget.bbclass        |  8 ++
 .../linux/files/debian/control.tmpl           | 15 +++-
 .../linux/files/debian/isar/build.tmpl        | 13 +++-
 .../linux/files/debian/isar/common.tmpl       | 11 +++
 .../linux/files/debian/isar/install.tmpl      | 75 ++++++++++++++-----
 meta/recipes-kernel/linux/linux-custom.inc    | 70 +++++++++++++----
 7 files changed, 167 insertions(+), 43 deletions(-)
 create mode 100644 meta/recipes-kernel/linux/classes/kbuildtarget.bbclass

-- 
2.39.2

[PATCH v5 1/4] linux-custom: Set PROVIDES variable using bitbake overrides

[Stefan Koch]

Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
---
 meta/recipes-kernel/linux/linux-custom.inc | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc
index 876397c3..14c7409b 100644
--- a/meta/recipes-kernel/linux/linux-custom.inc
+++ b/meta/recipes-kernel/linux/linux-custom.inc
@@ -96,15 +96,13 @@ KERNEL_NAME_PROVIDED ?= "${@ d.getVar('PN').partition('linux-')[2]}"
 
 # Make bitbake know we will be producing linux-image and linux-headers packages
 # Also make it know about other packages from control
-python() {
-    kernel_name = d.getVar("KERNEL_NAME_PROVIDED")
-    distro_arch = d.getVar("DISTRO_ARCH")
-    d.appendVar('PROVIDES', ' linux-image-' + kernel_name)
-    d.appendVar('PROVIDES', ' linux-headers-' + kernel_name)
-    d.appendVar('PROVIDES', ' linux-libc-dev')
-    d.appendVar('PROVIDES', ' linux-libc-dev-' + distro_arch + '-cross')
-    d.appendVar('PROVIDES', ' linux-image-' + kernel_name + '-dbg')
-}
+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 \
+"
 
 def get_kernel_arch(d):
     distro_arch = d.getVar("DISTRO_ARCH")
-- 
2.39.2

[PATCH v5 2/4] linux-custom: Split up binaries from kernel headers to kbuild package

[Stefan Koch]

This patch does introduce specific kernel kbuild packages that
ship the "scripts" and "tools" binaries.
The kernel headers fulfill this using symlinks to point
to the "scripts" and "tools" of the kernel kbuild package.

This is already known from debian kernel packages structure:
- Generate a kernel headers package without binaries
- Create kernel kbuild packages that
  ship the "scripts" and "tools" binaries
- Using symlinks to point to the "scripts"
  and "tools" binaries

Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
---
 .../linux/files/debian/control.tmpl           |  9 +++-
 .../linux/files/debian/isar/common.tmpl       |  2 +
 .../linux/files/debian/isar/install.tmpl      | 51 +++++++++++++++----
 meta/recipes-kernel/linux/linux-custom.inc    |  4 ++
 4 files changed, 54 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-kernel/linux/files/debian/control.tmpl b/meta/recipes-kernel/linux/files/debian/control.tmpl
index 956db3e3..7f271367 100644
--- a/meta/recipes-kernel/linux/files/debian/control.tmpl
+++ b/meta/recipes-kernel/linux/files/debian/control.tmpl
@@ -26,7 +26,7 @@ Section: devel
 Provides: linux-kernel-headers
 Architecture: any
 Description: Linux support headers for userspace development
- This package provides userspaces headers from the Linux kernel.  These headers
+ This package provides userspaces headers from the Linux kernel. These headers
  are used by the installed headers for GNU glibc and other system libraries.
 
 Package: linux-libc-dev-${DISTRO_ARCH}-cross
@@ -46,3 +46,10 @@ Architecture: any
 Description: Linux kernel debugging symbols for @KR@
  This package will come in handy if you need to debug the kernel. It provides
  all the necessary debug symbols for the kernel and its modules.
+
+Package: linux-kbuild-${KERNEL_NAME_PROVIDED}
+Architecture: any
+Depends: ${perl:Depends}, ${shlib:Depends}
+Description: ${KERNEL_NAME_PROVIDED} Linux kbuild scripts and tools for @KR@
+ This package provides kernel kbuild scripts and tools for @KR@
+ This is useful for people who need to build external modules
diff --git a/meta/recipes-kernel/linux/files/debian/isar/common.tmpl b/meta/recipes-kernel/linux/files/debian/isar/common.tmpl
index 9babf9a4..0944e943 100644
--- a/meta/recipes-kernel/linux/files/debian/isar/common.tmpl
+++ b/meta/recipes-kernel/linux/files/debian/isar/common.tmpl
@@ -10,6 +10,7 @@ KERNEL_PKG_IMAGE=linux-image-${KERNEL_NAME_PROVIDED}
 KERNEL_PKG_KERN_HEADERS=linux-headers-${KERNEL_NAME_PROVIDED}
 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}
 
 # Constants
 KCONF=.config
@@ -21,6 +22,7 @@ deb_dbg_dir=${deb_img_dir}-dbg
 deb_kern_hdr_dir=${deb_top_dir}/${KERNEL_PKG_KERN_HEADERS}
 deb_libc_hdr_dir=${deb_top_dir}/${KERNEL_PKG_LIBC_HEADERS}
 deb_libc_hdr_cross_dir=${deb_top_dir}/${KERNEL_PKG_LIBC_HEADERS_CROSS}
+deb_kern_kbuild_dir=${deb_top_dir}/${KERNEL_PKG_KERN_KBUILD}
 
 # Array of packages to be generated
 declare -A kern_pkgs
diff --git a/meta/recipes-kernel/linux/files/debian/isar/install.tmpl b/meta/recipes-kernel/linux/files/debian/isar/install.tmpl
index e91d33bb..97780dcc 100644
--- a/meta/recipes-kernel/linux/files/debian/isar/install.tmpl
+++ b/meta/recipes-kernel/linux/files/debian/isar/install.tmpl
@@ -33,6 +33,7 @@ do_install() {
     # Trace what we do here
     set -x
 
+    # Run the install steps
     install_image
     if [ "${ARCH}" != "um" ]; then
         install_config
@@ -43,6 +44,10 @@ do_install() {
     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
 }
@@ -171,21 +176,15 @@ kernel_headers() {
     mkdir -p ${destdir}
     mkdir -p ${deb_kern_hdr_dir}/lib/modules/${krel}
 
-    (cd ${S}; find . -name 'Makefile*' -o -name 'Kconfig*' -o -name '*.pl') >>${src_hdr_files}
-    (cd ${S}; find arch/*/include include scripts -type f -o -type l) >>${src_hdr_files}
+    (cd ${S}; find . -not -path './scripts/*' -a -not -path './tools/*' -a \( -name 'Makefile*' -o -name 'Kconfig*' -o -name '*.pl' \)) >>${src_hdr_files}
+    (cd ${S}; find arch/*/include include -type f -o -type l) >>${src_hdr_files}
     (cd ${S}; find arch/${ARCH} -name module.lds -o -name Kbuild.platforms -o -name Platform) >>${src_hdr_files}
     (cd ${S}; find $(find arch/${ARCH} -name include -o -name scripts -type d) -type f) >>${src_hdr_files}
 
     if [ -n "${CONFIG_MODULES}" ]; then
         echo Module.symvers >> ${obj_hdr_files}
     fi
-    (cd ${O}; find arch/${ARCH}/include include scripts -type f) >>${obj_hdr_files}
-    if [ -n "${CONFIG_STACK_VALIDATION}" -o -n "${CONFIG_HAVE_OBJTOOL}" ]; then
-        (cd ${O}; find tools/objtool -type f -executable) >>${obj_hdr_files}
-    fi
-    if [ -n "${CONFIG_GCC_PLUGINS}" ]; then
-        (cd ${O}; find scripts/gcc-plugins -name *.so -o -name gcc-common.h) >>${obj_hdr_files}
-    fi
+    (cd ${O}; find arch/${ARCH}/include include -type f) >>${obj_hdr_files}
 
     # deploy files that were matched above
     tar -C ${S} -cf - -T - <${src_hdr_files} | tar -C ${destdir} -xf -
@@ -194,8 +193,11 @@ kernel_headers() {
     # add the kernel config
     cp ${O}/${KCONF} ${destdir}/.config
 
-    # handle kernel development tools
-    kernel_tools
+    # add symlink to scripts and tools directories
+    ln -sf ../../lib/linux-kbuild-${krel}/scripts ${destdir}/scripts
+    if [ -n "${CONFIG_STACK_VALIDATION}" -o -n "${CONFIG_HAVE_OBJTOOL}" ]; then
+        ln -sf ../../lib/linux-kbuild-${krel}/tools ${destdir}/tools
+    fi
 
     # create symlinks
     ln -sf /${kernel_headers_dir} ${deb_kern_hdr_dir}/lib/modules/${krel}/build
@@ -209,4 +211,31 @@ install_headers() {
     kernel_headers
 }
 
+install_kbuild() {
+    kernel_kbuild_dir=usr/lib/linux-kbuild-${krel}
+    destdir=${1}/${kernel_kbuild_dir}
+    src_kbuild_files=$(mktemp)
+    obj_kbuild_files=$(mktemp)
+
+    mkdir -p ${destdir}
+
+    (cd ${S}; find . -path './scripts/*' -a -path './tools/*' -a \( -name 'Makefile*' -o -name 'Kconfig*' -o -name '*.pl' \)) >>${src_kbuild_files}
+    (cd ${S}; find scripts -type f -o -type l) >>${src_kbuild_files}
+
+    (cd ${O}; find scripts -type f) >>${obj_kbuild_files}
+    if [ -n "${CONFIG_STACK_VALIDATION}" -o -n "${CONFIG_HAVE_OBJTOOL}" ]; then
+        (cd ${O}; find tools/objtool -type f -executable) >>${obj_kbuild_files}
+    fi
+    if [ -n "${CONFIG_GCC_PLUGINS}" ]; then
+        (cd ${O}; find scripts/gcc-plugins -name *.so -o -name gcc-common.h) >>${obj_kbuild_files}
+    fi
+
+    # deploy files that were matched above
+    tar -C ${S} -cf - -T - <${src_kbuild_files} | tar -C ${destdir} -xf -
+    tar -C ${O} -cf - -T - <${obj_kbuild_files} | tar -C ${destdir} -xf -
+
+    # handle kernel development tools
+    kernel_tools
+}
+
 main install ${*}
diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc
index 14c7409b..48d86c2a 100644
--- a/meta/recipes-kernel/linux/linux-custom.inc
+++ b/meta/recipes-kernel/linux/linux-custom.inc
@@ -104,6 +104,10 @@ PROVIDES += " \
     linux-image-${KERNEL_NAME_PROVIDED}-dbg \
 "
 
+# append headers depends
+HEADERS_DEPENDS = ", linux-kbuild-${KERNEL_NAME_PROVIDED}"
+KERNEL_HEADERS_DEBIAN_DEPENDS:append = "${HEADERS_DEPENDS}"
+
 def get_kernel_arch(d):
     distro_arch = d.getVar("DISTRO_ARCH")
     if distro_arch in ["amd64", "i386"]:
-- 
2.39.2

[PATCH v5 3/4] linux-custom: Provide target and host specific kernel kbuild packages

[Stefan Koch]

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    | 52 +++++++++++++++++--
 6 files changed, 101 insertions(+), 21 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 @@
+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 48d86c2a..3f71fd7e 100644
--- a/meta/recipes-kernel/linux/linux-custom.inc
+++ b/meta/recipes-kernel/linux/linux-custom.inc
@@ -84,30 +84,72 @@ TEMPLATE_VARS += "                \
     DISTRIBUTOR                   \
 "
 
-inherit dpkg
-inherit template
-
 # 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]}"
+
+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):
+        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"
+
+inherit dpkg
+inherit template
+inherit kbuildtarget
+
 def get_kernel_arch(d):
     distro_arch = d.getVar("DISTRO_ARCH")
     if distro_arch in ["amd64", "i386"]:
-- 
2.39.2

[PATCH v5 4/4] docs: Update custom_kernel docs for split up of kernel scripts and tools

[Stefan Koch]

Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
---
 doc/custom_kernel.md | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/doc/custom_kernel.md b/doc/custom_kernel.md
index 73987a5b..ce5f1bf7 100644
--- a/doc/custom_kernel.md
+++ b/doc/custom_kernel.md
@@ -38,12 +38,18 @@ The linux-custom recipe provides support for:
  7. Allow the name of the kernel image to be changed via `KERNEL_FILE` (defaults
     to `vmlinuz`)
 
- 8. Produce a `linux-headers` package which includes kernel headers and kbuild
-    scripts/tools
+ 8. Produce a `linux-headers` package which includes kernel headers
 
- 9. The `linux-headers` package shall support native and cross compiles of
-    out-of-tree kernel modules. However, when built in cross-compilation mode,
-    it cannot be used on the target so far.
+ 9. Produce a `linux-kbuild` package for both `target` and `host` arch
+    which includes kbuild scripts and tools.
+    Using `linux-kbuild` provides the package for the target and when
+    cross building `linux-kbuild-native` provides the package for the host.
+
+    So the `linux-headers` package supports native and cross compiles of
+    out-of-tree kernel modules. Even, when built in cross-compilation mode,
+    it can be used on the target using the `linux-kbuild` package.
+
+    Only the `host` specific package is built automatically at cross builds.
 
  10. Produce a `linux-libc-dev` package to support user-land builds
 
@@ -72,8 +78,6 @@ In the future, the recipe may be extended to:
 
  3. Be compatible with Ubuntu
 
- 4. When cross-building, generate kernel-headers for both host and target
-
 ## Examples
 
 The linux-custom recipe is currently used by the linux-mainline package and is
-- 
2.39.2

Re: [PATCH v5 4/4] docs: Update custom_kernel docs for split up of kernel scripts and tools

[MOESSBAUER, Felix]

On Wed, 2024-01-31 at 17:00 +0100, Stefan Koch wrote:
> Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
> ---
>  doc/custom_kernel.md | 18 +++++++++++-------
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/custom_kernel.md b/doc/custom_kernel.md
> index 73987a5b..ce5f1bf7 100644
> --- a/doc/custom_kernel.md
> +++ b/doc/custom_kernel.md
> @@ -38,12 +38,18 @@ The linux-custom recipe provides support for:
>   7. Allow the name of the kernel image to be changed via
> `KERNEL_FILE` (defaults
>      to `vmlinuz`)
>  
> - 8. Produce a `linux-headers` package which includes kernel headers
> and kbuild
> -    scripts/tools
> + 8. Produce a `linux-headers` package which includes kernel headers
>  
> - 9. The `linux-headers` package shall support native and cross
> compiles of
> -    out-of-tree kernel modules. However, when built in cross-
> compilation mode,
> -    it cannot be used on the target so far.
> + 9. Produce a `linux-kbuild` package for both `target` and `host`
> arch
> +    which includes kbuild scripts and tools.
> +    Using `linux-kbuild` provides the package for the target and
> when
> +    cross building `linux-kbuild-native` provides the package for
> the host.
> +
> +    So the `linux-headers` package supports native and cross
> compiles of
> +    out-of-tree kernel modules. Even, when built in cross-
> compilation mode,
> +    it can be used on the target using the `linux-kbuild` package.
> +
> +    Only the `host` specific package is built automatically at cross
> builds.

Hi Stefan,

thanks for this series. I tested it and it already improves the
situation a lot (e.g. no native binaries in the arm64 packages).

Just a minor thing: When emulating the compilation of a kernel module
for an otherwise cross-compiled kernel, the build still fails as the
wrong dependency is attracted. I guess this can easily be fixed in
module.inc:

1. add a debian dependency to the "correct" kbuild package (e.g. the
one for arm64)
2. add an explicit debian build dependency to the kbuild package for
the non-native arch (e.g. arm64).

Only do that on non-cross (bitbake via the bitbake var, debian either
via bitbake or via a build-profile selector, e.g. "[cross]").

Best regards,
Felix

>  
>   10. Produce a `linux-libc-dev` package to support user-land builds
>  
> @@ -72,8 +78,6 @@ In the future, the recipe may be extended to:
>  
>   3. Be compatible with Ubuntu
>  
> - 4. When cross-building, generate kernel-headers for both host and
> target
> -
>  ## Examples
>  
>  The linux-custom recipe is currently used by the linux-mainline
> package and is

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH v5 4/4] docs: Update custom_kernel docs for split up of kernel scripts and tools

[Koch, Stefan]

On Thu, 2024-02-01 at 10:35 +0000, Moessbauer, Felix (T CED OES-DE)
wrote:
> On Wed, 2024-01-31 at 17:00 +0100, Stefan Koch wrote:
> > Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
> > ---
> >  doc/custom_kernel.md | 18 +++++++++++-------
> >  1 file changed, 11 insertions(+), 7 deletions(-)
> > 
> > diff --git a/doc/custom_kernel.md b/doc/custom_kernel.md
> > index 73987a5b..ce5f1bf7 100644
> > --- a/doc/custom_kernel.md
> > +++ b/doc/custom_kernel.md
> > @@ -38,12 +38,18 @@ The linux-custom recipe provides support for:
> >   7. Allow the name of the kernel image to be changed via
> > `KERNEL_FILE` (defaults
> >      to `vmlinuz`)
> >  
> > - 8. Produce a `linux-headers` package which includes kernel
> > headers
> > and kbuild
> > -    scripts/tools
> > + 8. Produce a `linux-headers` package which includes kernel
> > headers
> >  
> > - 9. The `linux-headers` package shall support native and cross
> > compiles of
> > -    out-of-tree kernel modules. However, when built in cross-
> > compilation mode,
> > -    it cannot be used on the target so far.
> > + 9. Produce a `linux-kbuild` package for both `target` and `host`
> > arch
> > +    which includes kbuild scripts and tools.
> > +    Using `linux-kbuild` provides the package for the target and
> > when
> > +    cross building `linux-kbuild-native` provides the package for
> > the host.
> > +
> > +    So the `linux-headers` package supports native and cross
> > compiles of
> > +    out-of-tree kernel modules. Even, when built in cross-
> > compilation mode,
> > +    it can be used on the target using the `linux-kbuild` package.
> > +
> > +    Only the `host` specific package is built automatically at
> > cross
> > builds.
> 
> Hi Stefan,
> 
> thanks for this series. I tested it and it already improves the
> situation a lot (e.g. no native binaries in the arm64 packages).
> 
> Just a minor thing: When emulating the compilation of a kernel module
> for an otherwise cross-compiled kernel, the build still fails as the
> wrong dependency is attracted. I guess this can easily be fixed in
> module.inc:
> 

I have successful built a module that uses linux-module/module.inc

That works either using cross-compilation or using QEMU based target
compilation.

> 1. add a debian dependency to the "correct" kbuild package (e.g. the
> one for arm64)
Was automatically used (:arm64) when ISAR_CROSS_COMPILE = "0" otherwise
(:amd64)
> 2. add an explicit debian build dependency to the kbuild package for
> the non-native arch (e.g. arm64).
Was unchanged
> 
> Only do that on non-cross (bitbake via the bitbake var, debian either
> via bitbake or via a build-profile selector, e.g. "[cross]").
Was unchanged, too
> 
> Best regards,
> Felix
> 
Stefan
> >  
> >   10. Produce a `linux-libc-dev` package to support user-land
> > builds
> >  
> > @@ -72,8 +78,6 @@ In the future, the recipe may be extended to:
> >  
> >   3. Be compatible with Ubuntu
> >  
> > - 4. When cross-building, generate kernel-headers for both host and
> > target
> > -
> >  ## Examples
> >  
> >  The linux-custom recipe is currently used by the linux-mainline
> > package and is
> 
> -- 
> Siemens AG, Technology
> Linux Expert Center
> 
> 

-- 
Stefan Koch
Siemens AG
www.siemens.com

Re: [PATCH v5 4/4] docs: Update custom_kernel docs for split up of kernel scripts and tools

[MOESSBAUER, Felix]

> > Hi Stefan,
> > 
> > thanks for this series. I tested it and it already improves the
> > situation a lot (e.g. no native binaries in the arm64 packages).
> > 
> > Just a minor thing: When emulating the compilation of a kernel
> > module
> > for an otherwise cross-compiled kernel, the build still fails as
> > the
> > wrong dependency is attracted. I guess this can easily be fixed in
> > module.inc:
> > 
> 
> I have successful built a module that uses linux-module/module.inc
> 
> That works either using cross-compilation or using QEMU based target
> compilation.

Right, thanks for the clarification. In my tests I combined a cross-
compiled kernel with a qemu-based compile of a module (and vice versa).
These use-cases are pretty special, so I don't want to delay this
series. I'll send my Tested-by for the whole series.

Best regards,
Felix

> 
> > 1. add a debian dependency to the "correct" kbuild package (e.g.
> > the
> > one for arm64)
> Was automatically used (:arm64) when ISAR_CROSS_COMPILE = "0"
> otherwise
> (:amd64)
> > 2. add an explicit debian build dependency to the kbuild package
> > for
> > the non-native arch (e.g. arm64).
> Was unchanged
> > 
> > Only do that on non-cross (bitbake via the bitbake var, debian
> > either
> > via bitbake or via a build-profile selector, e.g. "[cross]").
> Was unchanged, too
> > 
> > Best regards,
> > Felix
> > 
> Stefan
> > 
-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH v5 0/4] linux-custom: Split up binaries from kernel headers to kbuild package

[MOESSBAUER, Felix]

Hi Stefan,

this works as expected and is a great improvement.
Thanks for the contribution.

Tested-by: Felix Moessbauer <felix.moessbauer@siemens.com>

BR Felix

On Wed, 2024-01-31 at 16:59 +0100, Stefan Koch wrote:
> Hi
> 
> This updated v5 patchset implement suggestions from reviewed v4
> patchset.
> It's now a set of four patches:
> - linux-custom: Set PROVIDES variable using bitbake overrides
> - linux-custom: Split up binaries from kernel headers to kbuild
> package
> - linux-custom: Provide target and host specific kernel kbuild
> packages
> - docs: Update custom_kernel docs for split up of kernel scripts and
> tools
> 
> The first commit sets the PROVIDES variable using
> bitbake overrides instead of python code.
> 
> Swap out the binaries from the kernel headers
> into kernel kbuild package is the main use-case
> introduced by the second commit
> "Split up binaries from kernel headers to kbuild package"
> 
> The third commit "Provide target and host specific kernel kbuild
> packages"
> introduces that the binaries could be swapped out into host and
> target
> specific kernel kbuild packages.
> 
> These are the main development goals:
> 
> 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, and use the new linux-kbuild bitbake target
>   to create the kbuild target package when cross building
> 
> Best regards
> 
> Stefan
> 
> Stefan Koch (4):
>   linux-custom: Set PROVIDES variable using bitbake overrides
>   linux-custom: Split up binaries from kernel headers to kbuild
> package
>   linux-custom: Provide target and host specific kernel kbuild
> packages
>   docs: Update custom_kernel docs for split up of kernel scripts and
>     tools
> 
>  doc/custom_kernel.md                          | 18 +++--
>  .../linux/classes/kbuildtarget.bbclass        |  8 ++
>  .../linux/files/debian/control.tmpl           | 15 +++-
>  .../linux/files/debian/isar/build.tmpl        | 13 +++-
>  .../linux/files/debian/isar/common.tmpl       | 11 +++
>  .../linux/files/debian/isar/install.tmpl      | 75 ++++++++++++++---
> --
>  meta/recipes-kernel/linux/linux-custom.inc    | 70 +++++++++++++----
>  7 files changed, 167 insertions(+), 43 deletions(-)
>  create mode 100644 meta/recipes-
> kernel/linux/classes/kbuildtarget.bbclass
> 

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH v5 4/4] docs: Update custom_kernel docs for split up of kernel scripts and tools

[Koch, Stefan]

On Tue, 2024-02-06 at 12:50 +0000, Moessbauer, Felix (T CED OES-DE)
wrote:
> > > Hi Stefan,
> > > 
> > > thanks for this series. I tested it and it already improves the
> > > situation a lot (e.g. no native binaries in the arm64 packages).
> > > 
> > > Just a minor thing: When emulating the compilation of a kernel
> > > module
> > > for an otherwise cross-compiled kernel, the build still fails as
> > > the
> > > wrong dependency is attracted. I guess this can easily be fixed
> > > in
> > > module.inc:
> > > 
> > 
> > I have successful built a module that uses linux-module/module.inc
> > 
> > That works either using cross-compilation or using QEMU based
> > target
> > compilation.
> 
> Right, thanks for the clarification. In my tests I combined a cross-
> compiled kernel with a qemu-based compile of a module (and vice
> versa).
> These use-cases are pretty special, so I don't want to delay this
> series. I'll send my Tested-by for the whole series.

Same in my test case. Cross compiled kernel and built both kbuild
packages (native+target) and build module using qemu (and cross) - both
working.
> 
> Best regards,
> Felix
> 
> > 
> > > 1. add a debian dependency to the "correct" kbuild package (e.g.
> > > the
> > > one for arm64)
> > Was automatically used (:arm64) when ISAR_CROSS_COMPILE = "0"
> > otherwise
> > (:amd64)
> > > 2. add an explicit debian build dependency to the kbuild package
> > > for
> > > the non-native arch (e.g. arm64).
> > Was unchanged
> > > 
> > > Only do that on non-cross (bitbake via the bitbake var, debian
> > > either
> > > via bitbake or via a build-profile selector, e.g. "[cross]").
> > Was unchanged, too
> > > 
> > > Best regards,
> > > Felix
> > > 
> > Stefan
> > > 
> -- 
> Siemens AG, Technology
> Linux Expert Center
> 
> 

-- 
Stefan Koch
Siemens AG
www.siemens.com