From: Jan Kiszka <jan.kiszka@siemens.com>
To: Adriaan Schmidt <adriaan.schmidt@siemens.com>,
isar-users@googlegroups.com
Cc: stefan-koch@siemens.com
Subject: Re: [PATCH v3 1/3] module.inc: fix kbuild dependency
Date: Mon, 13 May 2024 09:02:26 +0200 [thread overview]
Message-ID: <26ab6ab8-3ec8-41fe-be66-8ff9cfe35dc7@siemens.com> (raw)
In-Reply-To: <9dab292b-4006-4bbe-9b2b-1d91106630b1@siemens.com>
On 13.05.24 07:24, Jan Kiszka wrote:
> On 13.05.24 06:17, Adriaan Schmidt wrote:
>> This achieves two things:
>>
>> * Module builds explicitly depend on linux-kbuild-* as build dependency.
>> Previously we only had an implicit RDEPENDS in linux-custom, which is
>> not sufficient. For linux-distro, this means we need to PROVIDE linux-kbuild.
>> * Remove the unconditional building of native kbuild when it is
>> not needed, i.e. when we're not actually cross-building a module
>>
>> Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
>> ---
>> meta/recipes-kernel/linux-module/module.inc | 3 ++-
>> meta/recipes-kernel/linux/linux-custom.inc | 3 ---
>> meta/recipes-kernel/linux/linux-distro.bb | 1 +
>> 3 files changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/meta/recipes-kernel/linux-module/module.inc b/meta/recipes-kernel/linux-module/module.inc
>> index eddbf177..1cca9cfb 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}"
>> +DEPENDS += "${KERNEL_HEADERS_PKG} ${KERNEL_KBUILD_PKG}-native"
>> DEBIAN_BUILD_DEPENDS = "${KERNEL_HEADERS_PKG}"
>>
>> SIGNATURE_KEYFILE ??= ""
>> diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc
>> index 0d222332..35c61187 100644
>> --- a/meta/recipes-kernel/linux/linux-custom.inc
>> +++ b/meta/recipes-kernel/linux/linux-custom.inc
>> @@ -148,9 +148,6 @@ 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"]:
>> 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'):
>
> There is another change coming with this: In order to install
> linux-headers into your target image, you now need to explicitly depend
> on linux-${KERNEL_NAME}-kbuildtarget in the image recipe.
> linux-headers-${KERNEL_NAME} will not pull the kbuildtarget, and the
> latter is not auto-built anymore.
>
> I'm testing some idea (some may call it hack) to resolve that by moving
> the linux-headers provider to kbuildtarget and native and then let those
> two depend on the base recipe. Not straightforward, but it seems to work.
>
The following changes on top of the this patch is apparently working
fine, and you can simply do
IMAGE_INSTALL += "linux-headers-${KERNEL_NAME}"
again.
diff --git a/meta/recipes-kernel/linux-module/module.inc b/meta/recipes-kernel/linux-module/module.inc
index 1cca9cfb..229e6a5c 100644
--- a/meta/recipes-kernel/linux-module/module.inc
+++ b/meta/recipes-kernel/linux-module/module.inc
@@ -17,8 +17,7 @@ PN .= "-${KERNEL_NAME}"
KERNEL_IMAGE_PKG ??= "linux-image-${KERNEL_NAME}"
KERNEL_HEADERS_PKG ??= "linux-headers-${KERNEL_NAME}"
-KERNEL_KBUILD_PKG ??= "linux-kbuild-${KERNEL_NAME}"
-DEPENDS += "${KERNEL_HEADERS_PKG} ${KERNEL_KBUILD_PKG}-native"
+DEPENDS += "${KERNEL_HEADERS_PKG}-native"
DEBIAN_BUILD_DEPENDS = "${KERNEL_HEADERS_PKG}"
SIGNATURE_KEYFILE ??= ""
diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc
index af3504dd..00b169bc 100644
--- a/meta/recipes-kernel/linux/linux-custom.inc
+++ b/meta/recipes-kernel/linux/linux-custom.inc
@@ -113,11 +113,19 @@ BUILD_PROFILES:cross-profile = "kernel"
# -native: kbuild package for host
BUILD_PROFILES:class-native = "kbuild"
-RECIPE_PROVIDES:class-native = "linux-kbuild-${KERNEL_NAME_PROVIDED}-native"
+RECIPE_PROVIDES:class-native = " \
+ linux-headers-${KERNEL_NAME_PROVIDED}-native \
+ linux-kbuild-${KERNEL_NAME_PROVIDED}-native"
+# Use pseudo target. We cannot use ${BPN} because it will be auto-extended
+# with -native by multiarch.bbclass.
+RDEPENDS:class-native = "${BPN}-pseudo-native"
# -kbuildtarget: kbuild package for target, enforcing non-cross-build
BUILD_PROFILES:class-kbuildtarget = "kbuild"
-RECIPE_PROVIDES:class-kbuildtarget = "linux-kbuild-${KERNEL_NAME_PROVIDED}"
+RECIPE_PROVIDES:class-kbuildtarget = " \
+ linux-headers-${KERNEL_NAME_PROVIDED} \
+ linux-kbuild-${KERNEL_NAME_PROVIDED}"
+RDEPENDS:class-kbuildtarget = "${BPN}"
ISAR_CROSS_COMPILE:class-kbuildtarget = "0"
# Make bitbake know we will be producing linux-image and linux-headers packages
@@ -125,15 +133,21 @@ ISAR_CROSS_COMPILE:class-kbuildtarget = "0"
RECIPE_PROVIDES = " \
linux-image-${KERNEL_NAME_PROVIDED} \
linux-headers-${KERNEL_NAME_PROVIDED} \
+ linux-headers-${KERNEL_NAME_PROVIDED}-native \
linux-libc-dev \
linux-libc-dev-${DISTRO_ARCH}-cross \
linux-image-${KERNEL_NAME_PROVIDED}-dbg \
linux-kbuild-${KERNEL_NAME_PROVIDED} \
+ ${BPN}-pseudo-native \
"
# 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}"
+# kbuild package is provided by -native or -kbuildtarget variant. Also headers
+# provisioning moves over to ensure those variants are pulled, although the
+# package itself is still built by the base recipe.
+RECIPE_PROVIDES:remove:cross-profile = " \
+ linux-headers-${KERNEL_NAME_PROVIDED} \
+ linux-headers-${KERNEL_NAME_PROVIDED}-native \
+ linux-kbuild-${KERNEL_NAME_PROVIDED}"
# Append headers depends
HEADERS_DEPENDS = ", linux-kbuild-${KERNEL_NAME_PROVIDED} | linux-kbuild-${KERNEL_NAME_PROVIDED}-${DISTRO_ARCH}-cross"
Jan
--
Siemens AG, Technology
Linux Expert Center
next prev parent reply other threads:[~2024-05-13 7:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 4:17 [PATCH v3 0/3] Kbuild follow-up Adriaan Schmidt
2024-05-13 4:17 ` [PATCH v3 1/3] module.inc: fix kbuild dependency Adriaan Schmidt
2024-05-13 5:24 ` Jan Kiszka
2024-05-13 7:02 ` Jan Kiszka [this message]
2024-05-13 4:17 ` [PATCH v3 2/3] linux-custom: use to_boolean when checking ISAR_CROSS_COMPILE Adriaan Schmidt
2024-05-13 7:45 ` Koch, Stefan
2024-05-13 9:06 ` Koch, Stefan
2024-05-13 4:17 ` [PATCH v3 3/3] kbuildtarget.bbclass: add missing license header Adriaan Schmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26ab6ab8-3ec8-41fe-be66-8ff9cfe35dc7@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=adriaan.schmidt@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=stefan-koch@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox