* [PATCH v6 1/5] linux-custom: Set PROVIDES variable using bitbake overrides
2024-02-14 10:10 [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package Stefan Koch
@ 2024-02-14 10:10 ` Stefan Koch
2024-02-14 10:10 ` [PATCH v6 2/5] linux-custom: Split up binaries from kernel headers to kbuild package Stefan Koch
` (6 subsequent siblings)
7 siblings, 0 replies; 19+ messages in thread
From: Stefan Koch @ 2024-02-14 10:10 UTC (permalink / raw)
To: isar-users
Cc: stefan-koch, jan.kiszka, christian.storm, michael.adler,
simon.sudler, cedric.hombourger, adriaan.schmidt,
felix.moessbauer, ubely
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH v6 2/5] linux-custom: Split up binaries from kernel headers to kbuild package
2024-02-14 10:10 [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package Stefan Koch
2024-02-14 10:10 ` [PATCH v6 1/5] linux-custom: Set PROVIDES variable using bitbake overrides Stefan Koch
@ 2024-02-14 10:10 ` Stefan Koch
2024-02-14 10:10 ` [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages Stefan Koch
` (5 subsequent siblings)
7 siblings, 0 replies; 19+ messages in thread
From: Stefan Koch @ 2024-02-14 10:10 UTC (permalink / raw)
To: isar-users
Cc: stefan-koch, jan.kiszka, christian.storm, michael.adler,
simon.sudler, cedric.hombourger, adriaan.schmidt,
felix.moessbauer, ubely
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..cbd23dc2 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
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages
2024-02-14 10:10 [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package Stefan Koch
2024-02-14 10:10 ` [PATCH v6 1/5] linux-custom: Set PROVIDES variable using bitbake overrides Stefan Koch
2024-02-14 10:10 ` [PATCH v6 2/5] linux-custom: Split up binaries from kernel headers to kbuild package Stefan Koch
@ 2024-02-14 10:10 ` Stefan Koch
2024-05-05 17:16 ` Jan Kiszka
` (2 more replies)
2024-02-14 10:10 ` [PATCH v6 4/5] linux-module: Support emulated module build with cross-compiled kernel Stefan Koch
` (4 subsequent siblings)
7 siblings, 3 replies; 19+ messages in thread
From: Stefan Koch @ 2024-02-14 10:10 UTC (permalink / raw)
To: isar-users
Cc: stefan-koch, jan.kiszka, christian.storm, michael.adler,
simon.sudler, cedric.hombourger, adriaan.schmidt,
felix.moessbauer, ubely
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 @@
+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"]:
--
2.39.2
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages
2024-02-14 10:10 ` [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages Stefan Koch
@ 2024-05-05 17:16 ` Jan Kiszka
2024-05-06 10:07 ` Koch, Stefan
2024-05-06 6:22 ` Jan Kiszka
2024-07-04 6:12 ` Anton Mikanovich
2 siblings, 1 reply; 19+ messages in thread
From: Jan Kiszka @ 2024-05-05 17:16 UTC (permalink / raw)
To: Stefan Koch, isar-users
Cc: christian.storm, michael.adler, simon.sudler, cedric.hombourger,
felix.moessbauer, ubely, adriaan.schmidt
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
--
Siemens AG, Technology
Linux Expert Center
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages
2024-05-05 17:16 ` Jan Kiszka
@ 2024-05-06 10:07 ` Koch, Stefan
2024-05-06 10:46 ` Jan Kiszka
0 siblings, 1 reply; 19+ messages in thread
From: Koch, Stefan @ 2024-05-06 10:07 UTC (permalink / raw)
To: isar-users, Kiszka, Jan
Cc: Sudler, Simon, Storm, Christian, ubely, cedric.hombourger, Adler,
Michael, MOESSBAUER, Felix, Schmidt, Adriaan
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/
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages
2024-05-06 10:07 ` Koch, Stefan
@ 2024-05-06 10:46 ` Jan Kiszka
0 siblings, 0 replies; 19+ messages in thread
From: Jan Kiszka @ 2024-05-06 10:46 UTC (permalink / raw)
To: Koch, Stefan (DI PA DCP R&D 3), isar-users
Cc: Sudler, Simon (DI PA DCP TI), Storm, Christian (T CED OES-DE),
ubely, Hombourger, Cedric (DI CTO FDS CES LX),
Adler, Michael (T CED OES-DE), Moessbauer, Felix (T CED OES-DE),
Schmidt, Adriaan (T CED EDC-DE)
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
--
Siemens AG, Technology
Linux Expert Center
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages
2024-02-14 10:10 ` [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages Stefan Koch
2024-05-05 17:16 ` Jan Kiszka
@ 2024-05-06 6:22 ` Jan Kiszka
2024-07-04 6:12 ` Anton Mikanovich
2 siblings, 0 replies; 19+ messages in thread
From: Jan Kiszka @ 2024-05-06 6:22 UTC (permalink / raw)
To: Stefan Koch, isar-users
Cc: christian.storm, michael.adler, simon.sudler, cedric.hombourger,
adriaan.schmidt, felix.moessbauer, ubely
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
--
Siemens AG, Technology
Linux Expert Center
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages
2024-02-14 10:10 ` [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages Stefan Koch
2024-05-05 17:16 ` Jan Kiszka
2024-05-06 6:22 ` Jan Kiszka
@ 2024-07-04 6:12 ` Anton Mikanovich
2024-07-04 12:44 ` 'Koch, Stefan' via isar-users
2 siblings, 1 reply; 19+ messages in thread
From: Anton Mikanovich @ 2024-07-04 6:12 UTC (permalink / raw)
To: Stefan Koch, isar-users
Cc: jan.kiszka, christian.storm, michael.adler, simon.sudler,
cedric.hombourger, adriaan.schmidt, felix.moessbauer, ubely,
Baurzhan Ismagulov
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?
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/a1b1badb-94aa-4d9e-87d4-3770eec7b7dc%40ilbers.de.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages
2024-07-04 6:12 ` Anton Mikanovich
@ 2024-07-04 12:44 ` 'Koch, Stefan' via isar-users
2024-07-04 13:02 ` 'cedric.hombourger@siemens.com' via isar-users
0 siblings, 1 reply; 19+ messages in thread
From: 'Koch, Stefan' via isar-users @ 2024-07-04 12:44 UTC (permalink / raw)
To: amikan, isar-users
Cc: Storm, Christian, ibr, cedric.hombourger, Adler, Michael, Sudler,
Simon, MOESSBAUER, Felix, Schmidt, Adriaan, Kiszka, Jan, ubely
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/
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/67f923d8daa2cb15cb332279fda31b38ed130fb1.camel%40siemens.com.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages
2024-07-04 12:44 ` 'Koch, Stefan' via isar-users
@ 2024-07-04 13:02 ` 'cedric.hombourger@siemens.com' via isar-users
2024-07-04 13:19 ` 'Koch, Stefan' via isar-users
0 siblings, 1 reply; 19+ messages in thread
From: 'cedric.hombourger@siemens.com' via isar-users @ 2024-07-04 13:02 UTC (permalink / raw)
To: Koch, Stefan, amikan, isar-users
Cc: Storm, Christian, ibr, Adler, Michael, Sudler, Simon, MOESSBAUER,
Felix, Schmidt, Adriaan, Kiszka, Jan, ubely
> ________________________________________
> 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
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/GV2PR10MB6137331E50C81AACAB1AD145FBDE2%40GV2PR10MB6137.EURPRD10.PROD.OUTLOOK.COM.
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages
2024-07-04 13:02 ` 'cedric.hombourger@siemens.com' via isar-users
@ 2024-07-04 13:19 ` 'Koch, Stefan' via isar-users
0 siblings, 0 replies; 19+ messages in thread
From: 'Koch, Stefan' via isar-users @ 2024-07-04 13:19 UTC (permalink / raw)
To: amikan, isar-users, cedric.hombourger
Cc: Storm, Christian, Adler, Michael, Sudler, Simon, ibr, MOESSBAUER,
Felix, Kiszka, Jan, Schmidt, Adriaan, ubely
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/
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/b11015b69f4c68b194bde2f00a7edcf9b1bba543.camel%40siemens.com.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v6 4/5] linux-module: Support emulated module build with cross-compiled kernel
2024-02-14 10:10 [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package Stefan Koch
` (2 preceding siblings ...)
2024-02-14 10:10 ` [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages Stefan Koch
@ 2024-02-14 10:10 ` Stefan Koch
2024-02-14 10:10 ` [PATCH v6 5/5] docs: Update custom_kernel docs for split up of kernel scripts and tools Stefan Koch
` (3 subsequent siblings)
7 siblings, 0 replies; 19+ messages in thread
From: Stefan Koch @ 2024-02-14 10:10 UTC (permalink / raw)
To: isar-users
Cc: stefan-koch, jan.kiszka, christian.storm, michael.adler,
simon.sudler, cedric.hombourger, adriaan.schmidt,
felix.moessbauer, ubely
Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
---
meta/recipes-kernel/linux-module/module.inc | 3 ++-
meta/recipes-kernel/linux/linux-distro.bb | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux-module/module.inc b/meta/recipes-kernel/linux-module/module.inc
index 269da6ae..51c89ccf 100644
--- a/meta/recipes-kernel/linux-module/module.inc
+++ b/meta/recipes-kernel/linux-module/module.inc
@@ -17,7 +17,8 @@ PN .= "-${KERNEL_NAME}"
KERNEL_IMAGE_PKG ??= "linux-image-${KERNEL_NAME}"
KERNEL_HEADERS_PKG ??= "linux-headers-${KERNEL_NAME}"
-DEPENDS += "${KERNEL_HEADERS_PKG}"
+KERNEL_KBUILD_PKG ??= "linux-kbuild-${KERNEL_NAME}-native"
+DEPENDS += "${KERNEL_HEADERS_PKG} ${KERNEL_KBUILD_PKG}"
DEBIAN_BUILD_DEPENDS = "${KERNEL_HEADERS_PKG}"
SIGNATURE_KEYFILE ??= ""
diff --git a/meta/recipes-kernel/linux/linux-distro.bb b/meta/recipes-kernel/linux/linux-distro.bb
index bc43528c..13b8dc7e 100644
--- a/meta/recipes-kernel/linux/linux-distro.bb
+++ b/meta/recipes-kernel/linux/linux-distro.bb
@@ -10,6 +10,7 @@ python() {
for kernel in distro_kernels.split():
d.appendVar('PROVIDES', ' linux-image-' + kernel)
d.appendVar('PROVIDES', ' linux-headers-' + kernel)
+ d.appendVar('PROVIDES', ' linux-kbuild-' + kernel)
if d.getVar('KERNEL_IMAGE_PKG'):
d.appendVar('PROVIDES', ' ' + d.getVar('KERNEL_IMAGE_PKG'))
if d.getVar('KERNEL_HEADERS_PKG'):
--
2.39.2
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH v6 5/5] docs: Update custom_kernel docs for split up of kernel scripts and tools
2024-02-14 10:10 [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package Stefan Koch
` (3 preceding siblings ...)
2024-02-14 10:10 ` [PATCH v6 4/5] linux-module: Support emulated module build with cross-compiled kernel Stefan Koch
@ 2024-02-14 10:10 ` Stefan Koch
2024-02-16 7:42 ` [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package MOESSBAUER, Felix
` (2 subsequent siblings)
7 siblings, 0 replies; 19+ messages in thread
From: Stefan Koch @ 2024-02-14 10:10 UTC (permalink / raw)
To: isar-users
Cc: stefan-koch, jan.kiszka, christian.storm, michael.adler,
simon.sudler, cedric.hombourger, adriaan.schmidt,
felix.moessbauer, ubely
Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
---
RECIPE-API-CHANGELOG.md | 31 +++++++++++++++++++++++++++++++
doc/custom_kernel.md | 18 +++++++++++-------
2 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
index bea12871..def1e7f2 100644
--- a/RECIPE-API-CHANGELOG.md
+++ b/RECIPE-API-CHANGELOG.md
@@ -566,3 +566,34 @@ supported, but a warning is issued when it is used. Future versions will drop
When building a custom kernel module, the `KBuild` file might be located in
a subdirectory. To support this use-case, set `MODULE_DIR=$(PWD)/subdir` in
the module build recipe.
+
+### Split up binaries from kernel headers to kbuild package for linux-custom
+
+Swap out the binaries from the kernel headers
+into kernel kbuild package.
+
+ * Split up binaries from kernel headers to kbuild package:
+ 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.
+
+ * Provide target and host specific kernel kbuild packages:
+ 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.
+
+ * Support emulated module build with cross-compiled kernel for linux-module
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
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package
2024-02-14 10:10 [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package Stefan Koch
` (4 preceding siblings ...)
2024-02-14 10:10 ` [PATCH v6 5/5] docs: Update custom_kernel docs for split up of kernel scripts and tools Stefan Koch
@ 2024-02-16 7:42 ` MOESSBAUER, Felix
2024-04-15 12:47 ` Uladzimir Bely
2024-04-23 19:22 ` Uladzimir Bely
7 siblings, 0 replies; 19+ messages in thread
From: MOESSBAUER, Felix @ 2024-02-16 7:42 UTC (permalink / raw)
To: isar-users, Koch, Stefan
Cc: Sudler, Simon, Storm, Christian, Schmidt, Adriaan, Kiszka, Jan,
Adler, Michael, cedric.hombourger, ubely
On Wed, 2024-02-14 at 11:10 +0100, Stefan Koch wrote:
> Hi
>
> This updated v6 patchset implement suggestions from reviewed v4
> patchset.
> It's now a set of five 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
> - linux-module: Support emulated module build with cross-compiled
> kernel
> - docs: Update custom_kernel docs for split up of kernel scripts and
> tools
Hi Stefan,
I tested this again and now also the cross-kernel / non-cross module
and vice versa properly works. Thanks!
Tested-by: Felix Moessbauer <felix.moessbauer@siemens.com>
Best regards,
Felix
>
> 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.
>
> Support of emulated module build with a cross-compiled kernel build
> is introduced by the fourth commit.
>
> 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 (5):
> 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
> linux-module: Support emulated module build with cross-compiled
> kernel
> docs: Update custom_kernel docs for split up of kernel scripts and
> tools
>
> RECIPE-API-CHANGELOG.md | 31 ++++++++
> doc/custom_kernel.md | 18 +++--
> meta/recipes-kernel/linux-module/module.inc | 3 +-
> .../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 | 65 +++++++++++++---
> meta/recipes-kernel/linux/linux-distro.bb | 1 +
> 10 files changed, 199 insertions(+), 41 deletions(-)
> create mode 100644 meta/recipes-
> kernel/linux/classes/kbuildtarget.bbclass
>
--
Siemens AG, Technology
Linux Expert Center
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package
2024-02-14 10:10 [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package Stefan Koch
` (5 preceding siblings ...)
2024-02-16 7:42 ` [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package MOESSBAUER, Felix
@ 2024-04-15 12:47 ` Uladzimir Bely
2024-04-17 9:29 ` Koch, Stefan
2024-04-23 19:22 ` Uladzimir Bely
7 siblings, 1 reply; 19+ messages in thread
From: Uladzimir Bely @ 2024-04-15 12:47 UTC (permalink / raw)
To: Stefan Koch, isar-users
On Wed, 2024-02-14 at 11:10 +0100, 'Stefan Koch' via isar-users wrote:
> Hi
>
> This updated v6 patchset implement suggestions from reviewed v4
> patchset.
> It's now a set of five 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
> - linux-module: Support emulated module build with cross-compiled
> kernel
> - 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.
>
> Support of emulated module build with a cross-compiled kernel build
> is introduced by the fourth commit.
>
> 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 (5):
> 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
> linux-module: Support emulated module build with cross-compiled
> kernel
> docs: Update custom_kernel docs for split up of kernel scripts and
> tools
>
> RECIPE-API-CHANGELOG.md | 31 ++++++++
> doc/custom_kernel.md | 18 +++--
> meta/recipes-kernel/linux-module/module.inc | 3 +-
> .../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 | 65 +++++++++++++---
> meta/recipes-kernel/linux/linux-distro.bb | 1 +
> 10 files changed, 199 insertions(+), 41 deletions(-)
> create mode 100644 meta/recipes-
> kernel/linux/classes/kbuildtarget.bbclass
>
> --
> 2.39.2
>
Hello Stefan.
Recently I run the patchset through CI and it failed (test 2 in "dev"
set) on amd64 targets with error like:
[stdlog] 2024-04-12 16:23:10,235 avocado.app cibuilder L0222
ERROR| ERROR: Nothing PROVIDES 'linux-kbuild-amd64-native' (but
mc:qemuamd64-bullseye:/workspace/build/isar_ub_devel_fast/567/meta-
isar/recipes-kernel/example-module/example-module.bb DEPENDS on or
otherwise requires it). Close matches:
[stdlog] 2024-04-12 16:23:10,235 avocado.app cibuilder L0222
ERROR| linux-kbuild-amd64
[stdlog] 2024-04-12 16:23:10,235 avocado.test cibuilder L0220
INFO |
[stdlog] 2024-04-12 16:23:10,235 avocado.app cibuilder L0222
ERROR| linux-kbuild-cip-native
[stdlog] 2024-04-12 16:23:10,235 avocado.app cibuilder L0222
ERROR| linux-kbuild-mainline-native
[stdlog] 2024-04-12 16:23:10,235 avocado.app cibuilder L0222
ERROR| ERROR: Required build target 'isar-image-ci' has no buildable
providers.
I tried to reproduce it locally, and the easiest way to reproduce was
the following:
```
./kas/kas-container menu
<Leave everything as is, just select "Save & Build">
...
Parsing recipes: 100%
|######################################################################
#########################################################| Time:
0:00:00
Parsing of 55 .bb files complete (0 cached, 55 parsed). 57 targets, 15
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'linux-kbuild-amd64-native' (but
/build/../repo/meta-isar/recipes-kernel/example-module/example-
module.bb DEPENDS on or otherwise requires it). Close matches:
linux-kbuild-amd64
linux-kbuild-cip-native
linux-kbuild-mainline-native
ERROR: Required build target 'isar-image-base' has no buildable
providers.
Missing or unbuildable dependency chain was: ['isar-image-base',
'example-module-amd64', 'linux-kbuild-amd64-native']
```
I also tried the patchset with older Isar (e.g. just some commits
before v0.10, when the patchset was released) and the situation looks
the same.
When we remove "example-module" from list of packages to install, build
is OK.
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package
2024-04-15 12:47 ` Uladzimir Bely
@ 2024-04-17 9:29 ` Koch, Stefan
0 siblings, 0 replies; 19+ messages in thread
From: Koch, Stefan @ 2024-04-17 9:29 UTC (permalink / raw)
To: ubely, isar-users
Cc: Sudler, Simon, Storm, Christian, Schmidt, Adriaan, Kiszka, Jan,
Adler, Michael, MOESSBAUER, Felix, cedric.hombourger
On Mon, 2024-04-15 at 15:47 +0300, Uladzimir Bely wrote:
> On Wed, 2024-02-14 at 11:10 +0100, 'Stefan Koch' via isar-users
> wrote:
> > Hi
> >
> > This updated v6 patchset implement suggestions from reviewed v4
> > patchset.
> > It's now a set of five 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
> > - linux-module: Support emulated module build with cross-compiled
> > kernel
> > - 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.
> >
> > Support of emulated module build with a cross-compiled kernel build
> > is introduced by the fourth commit.
> >
> > 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 (5):
> > 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
> > linux-module: Support emulated module build with cross-compiled
> > kernel
> > docs: Update custom_kernel docs for split up of kernel scripts
> > and
> > tools
> >
> > RECIPE-API-CHANGELOG.md | 31 ++++++++
> > doc/custom_kernel.md | 18 +++--
> > meta/recipes-kernel/linux-module/module.inc | 3 +-
> > .../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 | 65 +++++++++++++--
> > -
> > meta/recipes-kernel/linux/linux-distro.bb | 1 +
> > 10 files changed, 199 insertions(+), 41 deletions(-)
> > create mode 100644 meta/recipes-
> > kernel/linux/classes/kbuildtarget.bbclass
> >
> > --
> > 2.39.2
> >
>
> Hello Stefan.
Hi
>
> Recently I run the patchset through CI and it failed (test 2 in "dev"
> set) on amd64 targets with error like:
>
> [stdlog] 2024-04-12 16:23:10,235 avocado.app cibuilder L0222
> ERROR| ERROR: Nothing PROVIDES 'linux-kbuild-amd64-native' (but
> mc:qemuamd64-bullseye:/workspace/build/isar_ub_devel_fast/567/meta-
> isar/recipes-kernel/example-module/example-module.bb DEPENDS on or
> otherwise requires it). Close matches:
> [stdlog] 2024-04-12 16:23:10,235 avocado.app cibuilder L0222
> ERROR| linux-kbuild-amd64
> [stdlog] 2024-04-12 16:23:10,235 avocado.test cibuilder L0220
> INFO |
> [stdlog] 2024-04-12 16:23:10,235 avocado.app cibuilder L0222
> ERROR| linux-kbuild-cip-native
> [stdlog] 2024-04-12 16:23:10,235 avocado.app cibuilder L0222
> ERROR| linux-kbuild-mainline-native
> [stdlog] 2024-04-12 16:23:10,235 avocado.app cibuilder L0222
> ERROR| ERROR: Required build target 'isar-image-ci' has no buildable
> providers.
>
> I tried to reproduce it locally, and the easiest way to reproduce was
> the following:
>
> ```
> ./kas/kas-container menu
> <Leave everything as is, just select "Save & Build">
> ...
> Parsing recipes: 100%
> > ###################################################################
> > ###
> #########################################################| Time:
> 0:00:00
> Parsing of 55 .bb files complete (0 cached, 55 parsed). 57 targets,
> 15
> skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing PROVIDES 'linux-kbuild-amd64-native' (but
> /build/../repo/meta-isar/recipes-kernel/example-module/example-
> module.bb DEPENDS on or otherwise requires it). Close matches:
> linux-kbuild-amd64
> linux-kbuild-cip-native
> linux-kbuild-mainline-native
> ERROR: Required build target 'isar-image-base' has no buildable
> providers.
> Missing or unbuildable dependency chain was: ['isar-image-base',
> 'example-module-amd64', 'linux-kbuild-amd64-native']
> ```
>
This is caused by commit:
"linux-module: Support emulated module build with cross-compiled
kernel"
It should be possible to skip this commit for the first time, fix it
meanwhile and apply this (then fixed) commit later.
> I also tried the patchset with older Isar (e.g. just some commits
> before v0.10, when the patchset was released) and the situation looks
> the same.
>
> When we remove "example-module" from list of packages to install,
> build
> is OK.
>
Thanks and regards
--
Stefan Koch
Siemens AG
www.siemens.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package
2024-02-14 10:10 [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package Stefan Koch
` (6 preceding siblings ...)
2024-04-15 12:47 ` Uladzimir Bely
@ 2024-04-23 19:22 ` Uladzimir Bely
2024-04-30 13:10 ` Koch, Stefan
7 siblings, 1 reply; 19+ messages in thread
From: Uladzimir Bely @ 2024-04-23 19:22 UTC (permalink / raw)
To: Stefan Koch, isar-users
Cc: jan.kiszka, christian.storm, michael.adler, simon.sudler,
cedric.hombourger, adriaan.schmidt, felix.moessbauer
On Wed, 2024-02-14 at 11:10 +0100, 'Stefan Koch' via isar-users wrote:
> Hi
>
> This updated v6 patchset implement suggestions from reviewed v4
> patchset.
> It's now a set of five 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
> - linux-module: Support emulated module build with cross-compiled
> kernel
> - 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.
>
> Support of emulated module build with a cross-compiled kernel build
> is introduced by the fourth commit.
>
> 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 (5):
> 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
> linux-module: Support emulated module build with cross-compiled
> kernel
> docs: Update custom_kernel docs for split up of kernel scripts and
> tools
>
> RECIPE-API-CHANGELOG.md | 31 ++++++++
> doc/custom_kernel.md | 18 +++--
> meta/recipes-kernel/linux-module/module.inc | 3 +-
> .../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 | 65 +++++++++++++---
> meta/recipes-kernel/linux/linux-distro.bb | 1 +
> 10 files changed, 199 insertions(+), 41 deletions(-)
> create mode 100644 meta/recipes-
> kernel/linux/classes/kbuildtarget.bbclass
>
> --
> 2.39.2
>
Applied to next, excluding patch 4 (causing build failures on amd64
arch), as discussed on maillist.
Thanks.
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v6 0/5] linux-custom: Split up binaries from kernel headers to kbuild package
2024-04-23 19:22 ` Uladzimir Bely
@ 2024-04-30 13:10 ` Koch, Stefan
0 siblings, 0 replies; 19+ messages in thread
From: Koch, Stefan @ 2024-04-30 13:10 UTC (permalink / raw)
To: ubely, isar-users
Cc: Sudler, Simon, Storm, Christian, Schmidt, Adriaan, Kiszka, Jan,
Adler, Michael, MOESSBAUER, Felix, cedric.hombourger
On Tue, 2024-04-23 at 22:22 +0300, Uladzimir Bely wrote:
> On Wed, 2024-02-14 at 11:10 +0100, 'Stefan Koch' via isar-users
> wrote:
> > Hi
> >
> > This updated v6 patchset implement suggestions from reviewed v4
> > patchset.
> > It's now a set of five 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
> > - linux-module: Support emulated module build with cross-compiled
> > kernel
> > - 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.
> >
> > Support of emulated module build with a cross-compiled kernel build
> > is introduced by the fourth commit.
> >
> > 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 (5):
> > 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
> > linux-module: Support emulated module build with cross-compiled
> > kernel
> > docs: Update custom_kernel docs for split up of kernel scripts
> > and
> > tools
> >
> > RECIPE-API-CHANGELOG.md | 31 ++++++++
> > doc/custom_kernel.md | 18 +++--
> > meta/recipes-kernel/linux-module/module.inc | 3 +-
> > .../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 | 65 +++++++++++++--
> > -
> > meta/recipes-kernel/linux/linux-distro.bb | 1 +
> > 10 files changed, 199 insertions(+), 41 deletions(-)
> > create mode 100644 meta/recipes-
> > kernel/linux/classes/kbuildtarget.bbclass
> >
> > --
> > 2.39.2
> >
>
> Applied to next, excluding patch 4 (causing build failures on amd64
> arch), as discussed on maillist.
Thanks. I'll send fixed patch 4 now...
>
> Thanks.
--
Stefan Koch
Siemens AG
www.siemens.com
^ permalink raw reply [flat|nested] 19+ messages in thread