On 3/10/2026 12:50 AM, Richard Purdie wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Mon, 2026-03-09 at 14:01 -0400, Bruce Ashfield wrote:
On Mon, Mar 9, 2026 at 12:54 PM Harish Sadineni
<[email protected]> wrote:
On 3/9/2026 9:59 PM, Bruce Ashfield wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the
sender and know the content is safe.
On Mon, Mar 9, 2026 at 12:10 PM Harish Sadineni
<[email protected]> wrote:
On 3/9/2026 4:56 PM, Richard Purdie wrote:
CAUTION: This email comes from a non Wind River email
account!
Do not click links or open attachments unless you recognize
the sender and know the content is safe.
On Wed, 2026-03-04 at 09:43 -0800, Sadineni, Harish via
lists.openembedded.org wrote:
From: Harish Sadineni <[email protected]>
Conditionally add 'clang-native', 'rust-native' and
'bindgen-cli-native' to 'DEPENDS'
when Kernel Rust Support is enabled.
These tools are required for building Rust-enabled kernels
and for
generating Rust FFI bindings via bindgen during the kernel
build.
This ensures the additional dependencies are only pulled in
when
Rust support is explicitly enabled, avoiding unnecessary
native
dependencies for non-Rust kernel builds.
Signed-off-by: Harish Sadineni
<[email protected]>
---
meta/recipes-kernel/linux/linux-yocto.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index 4d0a726bb6..b7961bbcdf 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -76,11 +76,14 @@ do_install:append(){
KERNEL_FEATURES:append:qemuall = " features/kernel-
sample/kernel-sample.scc"
KERNEL_DEBUG ?= ""
+KERNEL_RUST_SUPPORT ?= ""
# These used to be version specific, but are now common
dependencies. New
# tools / dependencies will continue to be added in
version specific recipes.
DEPENDS += '${@bb.utils.contains_any("ARCH", [ "x86",
"arm64", "powerpc" ], "elfutils-native", "", d)}'
DEPENDS += "openssl-native util-linux-native"
DEPENDS += "gmp-native libmpc-native"
+RUST_KERNEL_DEPENDS ?=
"${@bb.utils.contains('KERNEL_RUST_SUPPORT', 'True',
'clang-native rust-native bindgen-cli-native', '', d)}"
+DEPENDS += "${RUST_KERNEL_DEPENDS}"
# Some options depend on CONFIG_PAHOLE_VERSION, so need to
make pahole-native available before do_kernel_configme
do_kernel_configme[depends] +=
'${@bb.utils.contains("KERNEL_DEBUG", "True", "pahole-
native:do_populate_sysroot", "", d)}'
I thought we were going to try and use KERNEL_FEATURES for
this?
Hi Richard,
I have tried this but i got circular dependency error with
KERNEL_FEATURES. So, I opted using variable
KERNEL_RUST_SUPPORT.
I'm curious about that. Can you share the details ? (diff and the
bitbake error)
As discussed previously, I attempted to use the following in
meta/recipes-kernel/linux/linux-yocto_6.18.bb:
KERNEL_FEATURES:append = " ${@bb.utils.contains('KERNEL_FEATURES',
'rust-kernel', ' features/kernel-rust/kernel-rust.scc', '', d)}"
This resulted in a BitBake variable dependency chain failure. The
issue occurs because the expression is trying to read
KERNEL_FEATURES
while simultaneously modifying KERNEL_FEATURES, which creates a
circular dependency.
Yes, that's clearly not going to work, but that wouldn't have been
the suggestion.
Wasn't Richard asking about setting the RUST_KERNEL_DEPENDS based on
the KERNEL_FEATURES containing rust.scc ?
We understood like Richard suggestion is to use KERNEL_FEATURES
everywhere instead of KERNEL_RUST_SUPPORT variable.
We can use the KERNEL_RUST_SUPPORT variable to append rust.scc to
KERNEL_FEATURES and then we could make other checks depends on
KERNEL_FEATURES.
But as the other recipes (make-mod-scripts, kernel-devsrc,
module-rust.bbclass) do not know about KERNEL_FEATURES, so again we've
to depend on KERNEL_RUST_SUPPORT Variable.
So, for consistency we used everywhere KERNEL_RUST_SUPPORT.
Is this implementation ok or we should switch to use -
KERNEL_FEATURES in kernel recipes and
KERNEL_RUST_SUPPORT in other recipes.
Thanks,
Harish
Yes, along with maybe with a tweak to the KERNEL_FEATURES code which
could expand " rust " or maybe " kernel-rust "in KERNEL_FEATURES into
"features/kernel-rust/kernel-rust.scc" too just so there was a nice
short cut for it?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#232768):
https://lists.openembedded.org/g/openembedded-core/message/232768
Mute This Topic: https://lists.openembedded.org/mt/118136909/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
