Message ID | 20240516061320.3015697-1-adriaan.schmidt@siemens.com |
---|---|
Headers | show |
Series | kbuild follow-up | expand |
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?
Uladzimir Bely <ubely@ilbers.de>, Dienstag, 2. Juli 2024 08:41: > 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? 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.