Just wanted to ask for some more information on this topic. I just wanted some more clarification on what it is doing. If no_std removes the standard library how can you use it? Also, wouldn’t this just be a simple project if all we have to do is setup the library. We aren’t writing the library. How does it take 350 hours?
If you use #![no_std] in Rust code, you can not use the standard library.
Simply put, the Rust compiler knows bare metal targets (architecture specific, no OS and no standard lib) and targets supporting an operating system (architecture specific, OS specific and with standard lib). For the later and in case of RTEMS someone needs to port the Rust standard lib to use RTEMS and to create and support a target at the Rust community.
The only Rust target available for RTEMS with standard library is armv7-rtems-eabihf at the time of writing.
Please see also,
- RTEMS User Manual – section Rust
- The paper linked in the post Paper: Viability of Rust for Avionics Software Development – Current status and way forward – among other things it discusses creating a Rust target for RTEMS.
- Rustc book – section Platform Support – i.e. avialbale Rust targets
armv7-rtems-eabihftarget documentation
Hi,
I did the port of the armv7 rtems port.
The stdlib uses OS services to implement it’s functionality. For example POSIX. However, there are differences in POSIX implementations depending on OS (e.g. FreeBSD, Linux) as well as targets (architectures as well as which C library is used).
So, one thing was to figure out which code paths of the stdlib to enable via the config switches).
The POSIX flavor of the stdlib then also depends on C bindings for the actual structs, types and functions which the target OS uses. These are collected in the libc FFI library.
So, for adding a new RTEMS target the already ported parts of the stdlib from the armv7 port should be reuseable as the config switches are only related to the OS. You would need to add the correct bindings to the libc library for a new architecture, though.
The big chunk of work I see, is to run the stdlib unit testsuite on the (emulated) target, so that we get an idea which parts of the stdlib actually work on RTEMS and where futher fixes are necessary. So, far I only tested it with some custom simple “Hello World” and very simple unit tests.