| Message ID | 20251230141540.1974380-4-Harish.Sadineni@windriver.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Enable rust support for linux kernel | expand |
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. Does this make sense as a distro feature or should we just do this all the time? Do the nativesdk components get packaged separately? If they were, we could then make that an SDK feature instead. What happens for on target kernel module development? Shouldn't there be a target package too? Cheers, Richard
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 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. > 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. Thanks, Harish > Cheers, > > Richard
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. 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? What are other build systems (gentoo for example) doing with their Rust builds to satisfy the kernel's rust requirements? > > 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. >> 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. ../Randy > > Thanks, > Harish >> Cheers, >> >> Richard
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
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
On Wed, 2026-01-07 at 13:21 -0500, Randy MacLeod wrote: > > 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: > > > 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? > In the scheme of things, 50MB is not great but probably ok. It will be compressed down for sstate and so on. It does however need to be in a separate target package, that is important. The win here is that if you change DISTRO_FEATURES, rust/rust-native shouldn't be rebuilding, which is worth a bit of disk usage, IMO at least. Cheers, Richard >
On Thu, Jan 8, 2026 at 4:22 AM Randy MacLeod via lists.openembedded.org <randy.macleod=windriver.com@lists.openembedded.org> wrote: > > 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 > +} Note you can just use the Rust bootstrap tool to install the source, see my patch here: https://lists.openembedded.org/g/openembedded-core/topic/patch_1_2_rust_install_the/117170671 That way you don't need to manually copy the files > + > 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. The kernel needs the Rust core souce as the kernel is cross compiling the Rust source in it's build system. It seems unlikely that other software will do the same. It's a bit of a niche Linux kernel thing to want to do. > > > 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? It's the core Rust library. Even if the kernel only uses a select number of files, those files will pull in other files and modules. Copying a subset of files would require editing the files to remove imports to the missing files and seems very prone to breakage. I agree 50MB isn't great, but it allows the rust-native package to build the kernel without rebuliding rust-native, which seems like a win. > > > > > 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? The Rust tooling actually does this (it's called rust-src) so maybe a rust-src-native package would be the way to go Alistair > > > > 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 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#229026): https://lists.openembedded.org/g/openembedded-core/message/229026 > Mute This Topic: https://lists.openembedded.org/mt/116997864/3619028 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alistair23@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On 1/12/2026 6:12 AM, Alistair Francis 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 Thu, Jan 8, 2026 at 4:22 AM Randy MacLeod via > lists.openembedded.org > <randy.macleod=windriver.com@lists.openembedded.org> wrote: >> 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 >> +} > Note you can just use the Rust bootstrap tool to install the source, > see my patch here: > https://lists.openembedded.org/g/openembedded-core/topic/patch_1_2_rust_install_the/117170671 > > That way you don't need to manually copy the files Yes, that works. However, when using the above method to install the sources, 'bitbake make-mod-scripts' fails with the following error: HOSTRUSTC scripts/generate_rust_target error: Unrecognized option: 'i' This issue occurs because CFLAGS are being passed to HOSTRUSTC. I have updated the flags in the make-mod-scripts recipe to align with the flags used by linux-yocto. In addition, I fixed some build path issues and packaged the Rust library sources separately. We are currently testing the changes and will send v3 within the next couple of days. Thanks, Harish > >> + >> 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. > The kernel needs the Rust core souce as the kernel is cross compiling > the Rust source in it's build system. > > It seems unlikely that other software will do the same. It's a bit of > a niche Linux kernel thing to want to do. > >> >> 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? > It's the core Rust library. Even if the kernel only uses a select > number of files, those files will pull in other files and modules. > Copying a subset of files would require editing the files to remove > imports to the missing files and seems very prone to breakage. > > I agree 50MB isn't great, but it allows the rust-native package to > build the kernel without rebuliding rust-native, which seems like a > win. > >> >> >> >> 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? > The Rust tooling actually does this (it's called rust-src) so maybe a > rust-src-native package would be the way to go > > Alistair > >> >> >> 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 >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#229026): https://lists.openembedded.org/g/openembedded-core/message/229026 >> Mute This Topic: https://lists.openembedded.org/mt/116997864/3619028 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alistair23@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >>
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"