From: Harish Sadineni <Harish.Sadineni@windriver.com>
To: Randy MacLeod <randy.macleod@windriver.com>,
Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Sundeep.Kokkonda@windriver.com, bruce.ashfield@gmail.com,
yoann.congal@smile.fr, elmehdi.younes@smile.fr,
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2 03/15] rust: install Rust library sources for 'make rustavailable' support
Date: Wed, 7 Jan 2026 22:04:27 +0530 [thread overview]
Message-ID: <663fe060-072a-43a4-b0f9-20e172007c47@windriver.com> (raw)
In-Reply-To: <6baec353-7ac4-4801-8e13-225e4d9432f2@windriver.com>
On 1/7/2026 12:29 AM, Randy MacLeod wrote:
> On 2026-01-05 11:24 a.m., Harish Sadineni wrote:
>>
>> On 12/30/2025 9:28 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 Tue, 2025-12-30 at 06:15 -0800, Sadineni, Harish via
>>> lists.openembedded.org wrote:
>>>> From: Harish Sadineni <Harish.Sadineni@windriver.com>
>>>>
>>>> The `make rustavailable` process (1) expects the Rust standard
>>>> library source files (e.g., `lib.rs`)
>>>> to be present in the `library/` directory under `rustlib/src/rust/`.
>>>>
>>>> This patch ensures the required sources are available by:
>>>> - Copying the `library/` directory from the Rust source tree into
>>>> `${TMPDIR}/work-shared/rust`
>>>> during the snapshot setup.
>>>> - Installing the `library/` directory into
>>>> `${SDKPATHNATIVE}/usr/lib/rustlib/src/rust` for the
>>>> `nativesdk` class, making them available in them available in sdk
>>>>
>>>> 1) See the kernel tree for Documentation/rust/quick-start.rst in
>>>> the section: Requirements: Building
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/rust/quick-start.rst#n145
>>>>
>>>>
>>>> Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
>>>> ---
>>>> meta/recipes-devtools/rust/rust_1.91.1.bb | 17 +++++++++++++++++
>>>> 1 file changed, 17 insertions(+)
>>>>
>>>> diff --git a/meta/recipes-devtools/rust/rust_1.91.1.bb
>>>> b/meta/recipes-devtools/rust/rust_1.91.1.bb
>>>> index a25f65f674..7644ecf2d2 100644
>>>> --- a/meta/recipes-devtools/rust/rust_1.91.1.bb
>>>> +++ b/meta/recipes-devtools/rust/rust_1.91.1.bb
>>>> @@ -63,6 +63,16 @@ do_rust_setup_snapshot () {
>>>> done
>>>> fi
>>>> }
>>>> +
>>>> +do_rust_setup_snapshot:append:class-native () {
>>>> + if ${@bb.utils.contains('DISTRO_FEATURES', 'rust-kernel',
>>>> 'true', 'false', d)}; then
>>>> + if [ ! -d "${TMPDIR}/work-shared/rust" ]; then
>>>> + mkdir -p ${TMPDIR}/work-shared/rust
>>>> + cp -r ${RUSTSRC}/library ${TMPDIR}/work-shared/rust/.
>>>> + fi
>>>> + fi
>>>> +}
>>>> +
>>>> addtask rust_setup_snapshot after do_unpack before do_configure
>>>> addtask do_test_compile after do_configure do_rust_gen_targets
>>>> do_rust_setup_snapshot[dirs] += "${WORKDIR}/rust-snapshot"
>>>> @@ -314,6 +324,13 @@ rust_do_install:class-nativesdk() {
>>>> export
>>>> CARGO_TARGET_${RUST_HOST_TRIPLE}_RUNNER="\$OECORE_NATIVE_SYSROOT/lib/${SDKLOADER}"
>>>> export CC_$RUST_HOST_CC="${CCACHE}${HOST_PREFIX}gcc"
>>>> EOF
>>>> +
>>>> + if ${@bb.utils.contains('DISTRO_FEATURES', 'rust-kernel',
>>>> 'true', 'false', d)}; then
>>>> + if [ ! -d ${D}${SDKPATHNATIVE}/usr/lib/rustlib/src/rust
>>>> ]; then
>>>> + mkdir -p
>>>> ${D}${SDKPATHNATIVE}/usr/lib/rustlib/src/rust
>>>> + cp -r --no-preserve=ownership ${S}/library
>>>> ${D}${SDKPATHNATIVE}/usr/lib/rustlib/src/rust/
>>>> + fi
>>>> + fi
>>>> }
>>>>
>>>> FILES:${PN} += "${base_prefix}/environment-setup.d"
>>> The commit message should mention the size of these files.
>> Ok sure, I will add file size in v3.
>>> Does this make sense as a distro feature or should we just do this
>>> all the time?
>> This is suggestion from Bruce that we take it as distro feature.
>> https://lists.openembedded.org/g/openembedded-core/message/225256
>
>
> Richard mentioned this thread in today's tech call when I asked for
> commentson the rust-kernel PR.
>
> Yes, the high level requirement is to have a DISTRO_FEATURE but
> common, infrastructure parts
> such as this code that just copies a hopefully small number of files
> around,
> and is part of the rust recipe, could and likely be done regardless of
> the rust-kernel DISTRO_FEATURE.
>
Ok sure, We will remove the dependency on DISTRO_FEATURE for copying
the library directory from rust recipe.
>
>
> We don't want the rust recipe to change based on a kernel config
> unless we *really* have to
> since that essentially doubles the testing that should be done or
> leaves a gap in testing of the
> rust builds. If you do that for the kernel first, then another recipe
> later, soon you have a maintenance mess.
>
> Also if the kernel needs these files, then it's likely that other
> software will need it as well.
> You should analyze why the kernel needs these files and why other
> recipes do not. Perhaps any
> kernel-like image will have the same requirement. Is there a baremetal
> image using rust anywhere
> that you can use to check on that? I looked but all I found was:
> https://github.com/ahcbb6/baremetal-helloqemu-rust
> Anyway, let's focus on the linux kernel's requirements for now.
>
>
> So, how many files are needed and how much FS space do they use?
>
The file size of the library directory is around 50MB.
>
>
> What are other build systems (gentoo for example) doing with their
> Rust builds to satisfy the kernel's rust requirements?
>
I will check and update on this.
>
>
>>
>> In future when rust is default in kernel we can change this, But till
>> then it is good to have it as a distro feature.
>>> Do the nativesdk components get packaged separately? If they were, we
>>> could then make that an SDK feature instead.
>> No, We are not packaging it separately.
>
>
> The questions seems to be whether we should create a separate
> packaging rule.
>
Now by default it is getting packaged with nativesdk-rust, Do we need a
separate packaging for libraries/files that being installed for rust in
kernel support?
>
>
>>> What happens for on target kernel module development? Shouldn't
>>> there be a target package too?
>> Yes, I have made the necessary changes to include Rust library for
>> target as well and have tested Rust-based kernel module development
>> on the target.
>> I will send updated patches with v3.
>
>
> Before you spend time on polishing v3 please explain what your
> workflow is, step by step,
> so we can be sure that things makes sense from a high level.
>
We will update the rust recipe to copy the required libs to target image
and then the below steps to be followed :
- Build the image by adding the required tools via IMAGE_INSTALL:append
( e.g kernel-devsrc, gcc, rust, cargo, bindgen-cli etc..).
- In /usr/src/kernel, run "make rustavailable" to verify Rust support
(This step will check all supporting tools are available for rust
support in kernel).
- Run "make menuconfig" and enable "CONFIG_RUST".
- Run "make scripts" and "make prepare".
- Write a kernel module in Rust & build the module using "make", which
generates the "module_name.ko" file.
- Load the module using "insmod module_name.ko".
Thanks,
Harish
> ../Randy
>
>
>>
>> Thanks,
>> Harish
>>> Cheers,
>>>
>>> Richard
>
>
> --
> # Randy MacLeod
> # Wind River Linux
next prev parent reply other threads:[~2026-01-07 16:34 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 14:15 [PATCH v2 00/15] Enable rust support for linux kernel Harish.Sadineni
2025-12-30 14:15 ` [PATCH v2 01/15] bindgen-cli: extend BBCLASSEXTEND to include nativesdk Harish.Sadineni
2026-01-12 0:10 ` [OE-core] " Alistair Francis
2025-12-30 14:15 ` [PATCH v2 02/15] linux-yocto: conditionally add clang/rust/bindgen-cli-native to DEPENDS Harish.Sadineni
2026-01-12 0:12 ` [OE-core] " Alistair Francis
2025-12-30 14:15 ` [PATCH v2 03/15] rust: install Rust library sources for 'make rustavailable' support Harish.Sadineni
2025-12-30 15:58 ` [OE-core] " Richard Purdie
2026-01-05 16:24 ` Harish Sadineni
2026-01-06 18:59 ` Randy MacLeod
2026-01-07 16:34 ` Harish Sadineni [this message]
2026-01-07 18:21 ` Randy MacLeod
2026-01-07 19:03 ` Richard Purdie
2026-01-12 0:42 ` Alistair Francis
2026-01-13 12:14 ` Harish Sadineni
2025-12-30 14:15 ` [PATCH v2 04/15] bitbake.conf: Include "rust-kernel" in native/nativesdk feature filters Harish.Sadineni
2025-12-30 14:15 ` [PATCH v2 05/15] kernel-yocto: enable Rust kernel support via rustavailable and staged rustlib sources Harish.Sadineni
2025-12-30 14:15 ` [PATCH v2 06/15] linux-yocto: enable Rust support in kernel configuration Harish.Sadineni
2025-12-30 14:15 ` [PATCH v2 07/15] kernel-yocto: Fix for buildpaths errors when rust is enabled for kernel Harish.Sadineni
2025-12-30 14:15 ` [PATCH v2 08/15] kernel-yocto.bbclass: Disable ccache when rust-kernel is enabled Harish.Sadineni
2026-01-14 15:41 ` alban.moizan
2025-12-30 14:15 ` [PATCH v2 09/15] kernel-devsrc: copying rust-kernel source to $kerneldir/build Harish.Sadineni
2025-12-30 14:15 ` [PATCH v2 10/15] selftest/cases/runtime_test: Add test for Linux Rust sample Harish.Sadineni
2026-01-05 9:32 ` [OE-core] " Mathieu Dubois-Briand
2026-01-08 9:39 ` Yoann Congal
2025-12-30 14:15 ` [PATCH v2 11/15] kernel.bbclass: Copy include/config/auto.conf in STAGING_KERNEL_BUILDDIR Harish.Sadineni
2025-12-30 14:15 ` [PATCH v2 12/15] kernel.bbclass: Export artifacts needed for out-of-tree Rust compilation Harish.Sadineni
2025-12-30 14:15 ` [PATCH v2 13/15] module.bbclass: Prepare out-of-tree rust module compilation Harish.Sadineni
2025-12-30 14:15 ` [PATCH v2 14/15] meta-skeleton: Add rust-out-of-tree-module recipe Harish.Sadineni
2025-12-30 14:15 ` [PATCH v2 15/15] runtime_test: Add rust-out-of-tree selftest Harish.Sadineni
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=663fe060-072a-43a4-b0f9-20e172007c47@windriver.com \
--to=harish.sadineni@windriver.com \
--cc=Sundeep.Kokkonda@windriver.com \
--cc=bruce.ashfield@gmail.com \
--cc=elmehdi.younes@smile.fr \
--cc=openembedded-core@lists.openembedded.org \
--cc=randy.macleod@windriver.com \
--cc=richard.purdie@linuxfoundation.org \
--cc=yoann.congal@smile.fr \
/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