[PATCH v4 0/3] kbuild follow-up

[Adriaan Schmidt]

Ok, this is indeed a tricky one...

It's based on the code from Stefan's "[PATCH] linux-module: Support
emulated module build with cross-compiled kernel" (replacing that patch),
and on the result of staring at dependency graphs with Jan.
This mainly addresses corner cases of the refactored kbuild packaging
when cross-compiling.

I've tested

- cross-compiled custom kernel and cross module build
- cross-compiled custom kernel and emulated module build
- distro kernel and emulated module build

Let me know if one of your use-cases is still missing.

Also including some fixups (p2-3) brought up in recent reviews on the ML.

Adriaan

changes since v3:
- (almost) restored the old API, where a module recipe only depends on
linux-headers-*. Now it's linux-headers-*-native.
- Removed the -native suffix from all PROVIDES and DEPENDS because
I realized that those are added automatically by the multiarch logic.
Only exception is the pseudo target used to pull in the base variant
(which builds the headers) into the native one (which builds the kbuild
tools). This still needs to be named "-native".

changes since v2:
- removed a forgotten line of testing code

changes since v1:
- always use linux-kbuild-native as build dependency, even for emulated
builds, because the multiarch logic will select the correct package


Adriaan Schmidt (3):
module.inc: fix kbuild dependency
linux-custom: use to_boolean when checking ISAR_CROSS_COMPILE
kbuildtarget.bbclass: add missing license header

meta/recipes-kernel/linux-module/module.inc | 2 +-
.../linux/classes/kbuildtarget.bbclass | 5 ++++
meta/recipes-kernel/linux/linux-custom.inc | 27 ++++++++++++-------
meta/recipes-kernel/linux/linux-distro.bb | 1 +
4 files changed, 25 insertions(+), 10 deletions(-)

--
2.39.2

[Adriaan Schmidt]

Signed-off-by: Adriaan Schmidt <adriaan...@siemens.com>
---
meta/recipes-kernel/linux/classes/kbuildtarget.bbclass | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass b/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass
index 26369861..648825e4 100644
--- a/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass
+++ b/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass
@@ -1,3 +1,8 @@
+# This software is a part of ISAR.
+# Copyright (C) 2024 Siemens AG
+#
+# SPDX-License-Identifier: MIT
+
python kbuildtarget_virtclass_handler() {
pn = e.data.getVar('PN')
if pn.endswith('-kbuildtarget'):
--
2.39.2

[Adriaan Schmidt]

we've changed style/convention in Isar sometime during the review of the
kbuild series, and this was missed.

Signed-off-by: Adriaan Schmidt <adriaan...@siemens.com>
---

meta/recipes-kernel/linux/linux-custom.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc
index 7b752f2b..3fd0c6c2 100644
--- a/meta/recipes-kernel/linux/linux-custom.inc
+++ b/meta/recipes-kernel/linux/linux-custom.inc
@@ -97,7 +97,7 @@ 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(":"):
+ if d.getVar("DISTRO_ARCH") != d.getVar("HOST_ARCH") and bb.utils.to_boolean(d.getVar("ISAR_CROSS_COMPILE")) and "class-native" not in d.getVar("OVERRIDES", True).split(":"):
d.appendVar("OVERRIDES", ":cross-profile")
}

--
2.39.2

[Adriaan Schmidt]

[Adriaan Schmidt]

Signed-off-by: Adriaan Schmidt <adriaan...@siemens.com>
---

[Adriaan Schmidt]

Ok, this is indeed a tricky one...

It's based on the code from Stefan's "[PATCH] linux-module: Support
emulated module build with cross-compiled kernel" (replacing that patch),
and on the result of staring at dependency graphs with Jan.
This mainly addresses corner cases of the refactored kbuild packaging
when cross-compiling.

I've tested

- cross-compiled custom kernel and cross module build
- cross-compiled custom kernel and emulated module build
- distro kernel and emulated module build

- distro kernel and native module build

Let me know if one of your use-cases is still missing.

Also including some fixups (p2-3) brought up in recent reviews on the ML.

Adriaan

changes since v4:
- Added "inherit multiarch" to linux-distro, so that dummy recipe PROVIDES
"-native" packages in native build cases.

changes since v3:
- (almost) restored the old API, where a module recipe only depends on
linux-headers-*. Now it's linux-headers-*-native.
- Removed the -native suffix from all PROVIDES and DEPENDS because
I realized that those are added automatically by the multiarch logic.
Only exception is the pseudo target used to pull in the base variant
(which builds the headers) into the native one (which builds the kbuild
tools). This still needs to be named "-native".

changes since v2:
- removed a forgotten line of testing code

changes since v1:
- always use linux-kbuild-native as build dependency, even for emulated
builds, because the multiarch logic will select the correct package


Adriaan Schmidt (3):
module.inc: fix kbuild dependency
linux-custom: use to_boolean when checking ISAR_CROSS_COMPILE
kbuildtarget.bbclass: add missing license header

meta/recipes-kernel/linux-module/module.inc | 2 +-
.../linux/classes/kbuildtarget.bbclass | 5 ++++
meta/recipes-kernel/linux/linux-custom.inc | 27 ++++++++++++-------

meta/recipes-kernel/linux/linux-distro.bb | 3 +++
4 files changed, 27 insertions(+), 10 deletions(-)

--
2.39.2

[Anton Mikanovich]

16/05/2024 09:13, 'Adriaan Schmidt' via isar-users wrote:
> Ok, this is indeed a tricky one...
>
> It's based on the code from Stefan's "[PATCH] linux-module: Support
> emulated module build with cross-compiled kernel" (replacing that patch),
> and on the result of staring at dependency graphs with Jan.
> This mainly addresses corner cases of the refactored kbuild packaging
> when cross-compiling.
>
> I've tested
>
> - cross-compiled custom kernel and cross module build
> - cross-compiled custom kernel and emulated module build
> - distro kernel and emulated module build
> - distro kernel and native module build
>
> Let me know if one of your use-cases is still missing.
>
> Also including some fixups (p2-3) brought up in recent reviews on the ML.
>
> Adriaan

Hello Adriaan,

Are you going to make any changes on this patchset?
If not, we are planning to merge it to next.

At least it looks good enough and pass all the test cases.

[Schmidt, Adriaan]

Anton Mikanovich <ami...@ilbers.de>, Mittwoch, 22. Mai 2024 08:43:

Hi Anton,

No more changes planned. As far as I'm concerned this is good to be merged.

Thanks,
Adriaan

[Anton Mikanovich]

16/05/2024 09:13, 'Adriaan Schmidt' via isar-users wrote:

Applied to next, thanks.

[Uladzimir Bely]

On Thu, 2024-05-16 at 08:13 +0200, 'Adriaan Schmidt' via isar-users
wrote:

> Ok, this is indeed a tricky one...
>
> It's based on the code from Stefan's "[PATCH] linux-module: Support
> emulated module build with cross-compiled kernel" (replacing that
> patch),
> and on the result of staring at dependency graphs with Jan.
> This mainly addresses corner cases of the refactored kbuild packaging
> when cross-compiling.
>
> I've tested
>
> - cross-compiled custom kernel and cross module build
> - cross-compiled custom kernel and emulated module build
> - distro kernel and emulated module build
> - distro kernel and native module build
>
> Let me know if one of your use-cases is still missing.
>
> Also including some fixups (p2-3) brought up in recent reviews on the
> ML.
>
> Adriaan
>

This might need some additional cosmetic changes.

I was debugging other (not related) issues and just noted that the
patchset brought some messages bitbake prints during parsing stage,
when amd64/arm64 targets (having "compat" alternative) are selected:

```
beagleplay, hikey:
NOTE: Multiple providers are available for linux-mainline-pseudo-native
(linux-mainline, linux-mainline-compat)

qemuarm64:
NOTE: Multiple providers are available for linux-image-arm64 (linux-
distro, linux-distro-compat)
NOTE: Multiple providers are available for linux-headers-arm64 (linux-
distro, linux-distro-compat)

qemuamd64, virtualbox:
NOTE: Multiple providers are available for linux-image-amd64 (linux-
distro, linux-distro-compat)
```

This doesn't make builds fail, but a bit messy.

It's possible to suppress the messages by specifying PREFERRED_PROVIDER
in machine configs. E.g., for qemuarm64.conf:

```
PREFERRED_PROVIDER_linux-image-${KERNEL_NAME} = "linux-distro"
PREFERRED_PROVIDER_linux-headers-${KERNEL_NAME} = "linux-distro"
```

But is thare probably some better place for this that would not require
editing multiple machine configs?

--
Best regards,
Uladzimir.

[Schmidt, Adriaan]

Uladzimir Bely <ub...@ilbers.de>, Dienstag, 2. Juli 2024 08:41:

Does it even make sense to have -compat variants of kernel packages?
If not, then I think it should be possible to disable them with a

ISAR_ENABLE_COMPAT_ARCH = "0"

on a per-recipe base, in linux-custom.inc and linux-distro.bb.

Adriaan


> --
> Best regards,
> Uladzimir.