Libstd support for SOLID and μITRON

Hello,

At my company, we are currently working to add Rust support to SOLID, our embedded software development platform that seamlessly integrates an RTOS, middleware, an IDE, and hardware. We would like to introduce new targets to Rust to allow SOLID applications to utilize Rust's full potential (most importantly the std support) as well as to encourage and foster the embedded developer community's interest in Rust.

The preliminary sketch of our current plan is something like the following:

  • Since SOLID-OS's kernels (modified TOPPERS kernels) were derived from the μITRON4.0 Specification (which is very popular in Japan), we will introduce std::sys::uitron, which is intended to cover all μITRON derivatives in a similar vein to std::sys::unix.

  • We will add a few targets based on std::sys::uitron: toppers-asp3 and toppers-fmp3 for the open-source bare kernels and kmc-solidasp3 and kmc-solidfmp3 for SOLID-OS. The new targets are duplicated for each supported architecture (e.g., aarch64-kmc-solidasp3, armv7a-toppers-asp3-eabi).

The questions are:

  • Are there any written guides I should follow for adding new targets? E.g., I noticed that libstd depends on libc, and libc has to be updated as well to support new targets. This means a new version of libc has to be released before libstd can be built for the new targets (barring dependencies.libc.{git, rev}). Is this correct?

  • Are there any guidelines ruling what kind of target belongs to the main source tree and what does't? (Since we are adding more than one target...)

  • What are the requirements for making restricted-std unnecessary?

1 Like

2803-target-tier-policy - The Rust RFC Book is the policy for new targets supported by rust. I think it satisfies the conditions for a tier 3 target.

At this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets.

However I am not sure if the following requirements are satisfied:

  • Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
    • [...]
    • Targets should not require proprietary (non-FOSS) components to link a functional binary or library.
    • "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
2 Likes

Hi @bjorn3,

Thank you for the response!

Yes, these requirements are satisfied. We do provide a proprietary toolchain, but the new targets can be fully compiled to functional artifacts using FOSS toolchains with no restrictions. And we intend to make the contribution available with no legal restrictions whatsoever.

1 Like

Regarding the use of libc, some platforms that don't fully implement everything in libc instead use their own crate: fortanix-sgx-abi, hermit-abi, wasi.

Assuming you have people prepared to help maintain it, and you meet all the tier 3 target policy requirements, you're welcome to make a compiler MCP proposing your target for tier 3. You'll want to full-quote those requirements and explain for each one how you meet it.

1 Like

Also worth noting, if you’re not already aware you can compile Rust for targets not included in the repo using the nightly custom target feature and -Zbuild-std. So if you want to build for a platform and can use nightly. You can try it out without having to build rustc from source.

https://docs.rust-embedded.org/embedonomicon/custom-target.html

1 Like

That doesn't work when you want libstd support, as it doesn't allow overriding the standard library sources.

Sure, it’s a not a full solution, but it is quicker to get something built and more shareable than a fork.