Re: [PATCH v6 3/5] linux-custom: Provide target and host specific kernel kbuild packages

[Jan Kiszka <jan.kiszka@siemens.com>]

On 06.05.24 12:07, Koch, Stefan (DI PA DCP R&D 3) wrote:
> On Sun, 2024-05-05 at 19:16 +0200, Jan Kiszka wrote:
>> On 14.02.24 11:10, Stefan Koch wrote:
>>> When using a cross build this patch does introduce
>>> target and host specific kernel kbuild packages that
>>> ship the "scripts" and "tools" binaries.
>>>
>>> The "-kbuildtarget" and "-native" multiarch bitbake targets are
>>> useable to run
>>> additional target or host specific builds for kbuild scripts and
>>> tools.
>>>
>>> Using the "-kbuildtarget" bitbake target enables the build of
>>> a target specific kbuild package at cross builds.
>>> So using "linux-kbuild" provides the package for the target
>>> platform.
>>>
>>> Using the "-native" bitbake target enables the build of
>>> a host specific kbuild package at cross builds.
>>> When cross building using "linux-kbuild-native"
>>> provides the package for the host platform.
>>>
>>> Only the "host" specific package is built automatically at cross
>>> builds.
>>>
>>> This solves this from doc/custom_kernel.inc:
>>> - The kernel headers package has not supported both native
>>>   and cross compilation of kernel modules when itself was cross
>>> built
>>> - Future roadmap: Generate kernel headers package for both host
>>>   and target when using a cross build
>>>
>>> Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
>>
>> This causes the kernel source packages being built twice, and the
>> result
>> is not even identical:
>>
>> ├── linux-starfive_6.6-visionfive2+r0.tar
>> │ ├── file list
>> │ │ @@ -28357,15 +28357,15 @@
>> │ │  -rw-r--r--   0        0        0     3843 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xor.c
>> │ │  -rw-r--r--   0        0        0    12021 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xts.c
>> │ │  -rw-r--r--   0        0        0     2445 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/xxhash_generic.c
>> │ │  -rw-r--r--   0        0        0     5090 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/crypto/zstd.c
>> │ │  drwxr-xr-x   0        0        0        0 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/
>> │ │  -rw-r--r--   0        0        0      162 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/changelog
>> │ │  -rw-r--r--   0        0        0        3 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/compat
>> │ │ --rw-r--r--   0        0        0     2694 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control
>> │ │ +-rw-r--r--   0        0        0     2664 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control
>> │ │  drwxr-xr-x   0        0        0        0 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/fragments/
>> │ │  -rw-r--r--   0        0        0      155 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/fragments/starfive2_e
>> xtra.cfg
>> │ │  drwxr-xr-x   0        0        0        0 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/
>> │ │  -rw-r--r--   0        0        0     1875 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/build
>> │ │  -rw-r--r--   0        0        0      355 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/clean
>> │ │  -rw-r--r--   0        0        0     1830 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/common
>> │ │  -rw-r--r--   0        0        0      587 2023-11-21
>> 02:56:42.000000 linux-
>> 9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/isar/configure
>> │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/control
>> │ │ @@ -12,15 +12,15 @@
>> │ │  Description: starfive Linux kernel, version @KR@
>> │ │   This package contains the Linux kernel, modules and
>> corresponding other
>> │ │   files, version: @KR@.
>> │ │
>> │ │  Package: linux-headers-starfive
>> │ │  Build-Profiles: <kernel>
>> │ │  Architecture: any
>> │ │ -Depends: libc6,                                   libssl3,,
>> linux-kbuild-starfive:amd64 | linux-kbuild-starfive, ${perl:Depends},
>> ${shlib:Depends}
>> │ │ +Depends: libc6,                                   libssl3,,
> This comes from here:
> meta/recipes-kernel/linux/linux-custom.inc:114-115
> 
> # Select correct kbuild package for isar cross-build
> HEADERS_DEPENDS:cross-profile = ", linux-kbuild-
> ${KERNEL_NAME_PROVIDED}:${HOST_ARCH} | linux-kbuild-
> ${KERNEL_NAME_PROVIDED}"

Should be become unconditional. But I'm not even sure about that
HOST_ARCH in it. That is normally not decided at control file level.

>> linux-kbuild-starfive, ${perl:Depends}, ${shlib:Depends}
>> │ │  Description: starfive Linux kernel headers for @KR@
>> │ │   This package provides kernel header files for @KR@ on riscv64
>> │ │   .
>> │ │   This is useful for people who need to build external modules
>> │ │
>> │ │  Package: linux-libc-dev
>> │ │  Build-Profiles: <!nolibcdev kernel>
>> │ ├── linux-9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4/debian/linux-
>> image-starfive.postinst
>> │ │ @@ -2,15 +2,15 @@
>> │ │  # based on
>> https://salsa.debian.org/kernel-team/linux/blob/479cb120ecb2b3f2c4d929a7b57860248d6f79bd/debian/templates/image.postinst.in
>> │ │  # SPDX-License-Identifier: GPL-2.0-only
>> │ │
>> │ │  # Tell initramfs builder whether it's wanted
>> │ │  export INITRD=Yes
>> │ │
>> │ │  version=@KR@
>> │ │ -image_path=/boot/vmlinux-${version}
>> │ │ +image_path=/boot/vmlinuz-${version}
> This comes from here:
> meta/recipes-kernel/linux/files/debian/isar/install.tmpl:25-29
> 
> case "${ARCH}" in
>     mips|powerpc|riscv|arm64) kimage_path="boot/vmlinux-${krel}"    ;;
>                           um) kimage_path="usr/bin/vmlinux-${krel}" ;;
>                            *) kimage_path="boot/vmlinuz-${krel}"    ;;

...and the fact that ARCH is not properly set across all build variants.
Was harmless so far, but better fix to avoid future surprises.

Jan

-- 
Siemens AG, Technology
Linux Expert Center