Rust for RTEMS [was: Re: Interested for GSoC 2023]

[Karel Gardas]

On 2/27/23 15:44, Joel Sherrill wrote:
> 
> 
> On Mon, Feb 27, 2023 at 5:00 AM Karel Gardas <karel at functional.vision> 
> wrote:
> 
> 
>     adjusting subject based on Jan request. Keeping whole Rust relevant
>     comments in.
> 
>     On 2/27/23 11:07, Jan.Sommer at dlr.de <mailto:Jan.Sommer at dlr.de> wrote:
>      >
>      >
>      >> -----Original Message-----
>      >> From: devel <devel-bounces at rtems.org
>     <mailto:devel-bounces at rtems.org>> On Behalf Of Karel Gardas
>      >> Sent: Montag, 27. Februar 2023 09:16
>      >> To: joel at rtems.org <mailto:joel at rtems.org>; Vihas Makwana
>     <makvihas at gmail.com <mailto:makvihas at gmail.com>>
>      >> Cc: rtems-devel at rtems.org <mailto:rtems-devel at rtems.org>
>     <devel at rtems.org <mailto:devel at rtems.org>>
>      >> Subject: Re: Interested for GSoC 2023
>      >>
>      >> On 2/27/23 02:16, Joel Sherrill wrote:
>      >>> Another GCC related project could be Rust RTEMS Support but I don't
>      >>> know what that entails beyond turning it on and seeing what goes
>      >>> wrong. I tried to build it last year and got far enough to
>     decide to
>      >>> wait before trying again.
>      >>
>      >> Not sure how far you went. The process is generally:
>      >>
>      >> (1) tune Rust compiler to cross-compile correctly for specific
>     hardware/os
>      >> platform. So basically you get no_std capable compiler
> 
> 
> You should be able to compile gcc rust NOW to target CPU-rtems. I would
> expect minor tweaking of configuration both in configure scripting and 
> likely
> in the Rust run-time libraries. For example, with the Standard C++ Library
> there are configuration settings for *-rtems which pick the threading and
> synchronization model. Rust's run-time adapter with GCC should be similar.

There is a slight misunderstanding going here. I'm not talking about 
gccrs rust frond-end project which got merged into GCC to become part of 
GCC 13 in autumn last year to be released this spring probably. I'm 
talking and AFAIK Jan too about real Rust as distributed/provided by 
https://www.rust-lang.org/.

The messages from gccrs project are kind of mixed and clearly warns that 
even with GCC 13, the front-end would be good just for GCC rust ongoing 
development and not yet for let say Rust code in Linux kernel. I write 
that not to play that attempt down, in fact gccrs people work is 
outstanding, I write that just to remark that it may take some time 
before it's ready for general "consumption".

Hence, when investigating Rust for RTEMS, I went to rust-lang.org and 
investigated that because after all, this is still reference Rust 
implementation...

>     Not sure if I did not confused you with my (2) libc remark. I of course
>     mean Rust's libc (that means rust code) to be build on top of
>     RTEMS/Newlib/libbsd combination. It'll be interesting project
>     especially
>     if the requirement later would be to support both binary targets: e.g.
>     RTEMS without libbsd (for smaller systems) and RTEMS with libbsd for
>     full-blown configuration. Anyway, for now, I would start with libbsd as
>     this should make project proceeding faster IMHO.
> 
> 
> You shouldn't need RTEMS or libbsd built until you link real executables
> you want to run. All needed POSIX headers are present from newlib.

But I'm at the stage I'd like to link my Rust hello world with RTEMS 
BSP, that's what someone expects at the end anyway. :-)

> I was test building rust just like C, C++, and Ada. Build the toolchain and
> then build RTEMS.

So you liked rust + RTEMS well? Cool!

Karel