Re: [OE-core] [PATCH v2 03/15] rust: install Rust library sources for 'make rustavailable' support

[Randy MacLeod <randy.macleod@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 8404 bytes --]

On 2026-01-07 11:34 a.m., Harish Sadineni wrote:
>
> 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.


Hold on, I said "small number of files...". See below.

>>
>>
>> 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.
>
>
I've been around since the 1990s, 50 MB doesn't seem small to me but
let's see what other people think.

Also, how may files is that?

What's the content?  ls -lR if the list isn't too long.

Does the kernel build need each and every file ? How did you check?
Can we automate the generation of the list of required files by scraping 
the data from the kernel perhaps?


>>
>>
>> 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.


Thanks.

>>
>>
>>>
>>> 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 :

This part we're still trying to work out...

> - Build the image by adding the required tools via 
> IMAGE_INSTALL:append ( e.g kernel-devsrc, gcc, rust, cargo, 
> bindgen-cli etc..).
>
We could create / extend a packagegroup or use:
    meta/recipes-extended/images/core-image-kernel-dev.bb

Bruce, what approach do you use / prefer ?


> - 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".


The rest seems sensible to a non-kernel guy like me.

Thanks,

../Randy

>
> Thanks,
> Harish
>
>> ../Randy
>>
>>
>>>
>>> Thanks,
>>> Harish
>>>> Cheers,
>>>>
>>>> Richard
>>
>>
>> -- 
>> # Randy MacLeod
>> # Wind River Linux


-- 
# Randy MacLeod
# Wind River Linux

[-- Attachment #2: Type: text/html, Size: 14838 bytes --]