Rust breakout session 2023

Find below the notes of the Rust breakout session from the RIOT Summit 2023

Summit 2023 breakout: Rust

(proposed by Emmanuel, notes by chysn)

Agenda:

  • Where do we want to be with Rust on RIOT in some years?
  • What is RIOT / how much can a RIOT-rs (itself being a prototype) be RIOT?

Jose: on embassy. Many components. Do we buy into smoltcp?
chrysn: no, the idea is to remain modular, and support several network stacks. eg people could still use gnrc also.

Oleg: Looks like path for C-RIOT to Rust-RIOT. On the long run, do we want to have mix? Maybe for smaller parts, but policy for new modules?

Martine: Why?

Oleg: Otherweise it’ll be chaotic; we’d maintain code in two languages.
Martine: Already have that, for different use cases.
Oleg: There are reasons why we might want to switch (not convinced but anyway). If we go there b/c we’re convinced, there is a reason.
Martine: More about existing modules and being solid.
Oleg: I’m more about new modules.
Martine: If contributor is more familiar with C?
Oleg: Trouble with reviewing.

Karl: If we say new-things-are-rust-only, that’s effectively deprecating C.

Emmanuel: We already have issues around people not feeling familiar enough to review things. What this prototype would do is joining embedded Rust movement, also getting interactions back. On deprecating-C / new-only-in-Rust: Not there; it’s not what we should do right now; don’t have the skills. Prototype shows smoother transition. Can still have new stuff in C. It’s just about enabling configs that are predominantly Rust.

Leandro: -hal and -nal: bringing in external de facto standards? Limits how we do things?

chrysn: somewhat, but I’ve been active in these communities. Experience shows it’s possible to extend Rust traits in embedded-hal or embedded-nal. We could go ahead and take part in the decision processes in these communities. If we have requirements that are not satisfied, it will usually be considered. Otherwise, we can still extend the traits. I don’t have we’ll have too much the case of completely separate / extra interfaces.

nmeum: so the +libs in Emmanuel/Kaspar slides on RIOT-rs could be the network stack?

Emmanuel: a network stack yes :wink:

chrysn: so, C/Make/.ld be around in parallel with cargo based builds? For how long?

Emmanuel: Don’t have answer. As long as user experience stays nice good, and any direction that has a chance to tend to improve our build system + tool chain is welcome?

Jose: Idea is to use less C. This is switching to Rust, and C is just another lang like C++ where we don’t have code but support apps (and exotic libs) in it?
chrysn: Stuff that’s good can stay in C if it’s good and until someone chooses to rewrite.
nmeum: Would be beneficial to get more security by rewriting.
Mikolai: It’s a new shiny thing and community is moving; and it’s much collab w/ other communities (and less burden but also more need for communication). So many pros. On downside, moving period is lots of double things and maintenance issues. Also, most ppl in RIOT are now C experts. Will community change (new ppl coming) or will ppl learn Rust?

teufelchen: RIOT has responsibility for next gen of computer scientist. Teach them Fortran or Rust.

Oleg: Martine said “Would it still be RIOT?”. One thing is the community. If we transit to a new community, it’s not RIOT any more. Only way forward here is if majority of community is convinced to go along and use Rust.

Martine: Maybe some current contributors don’t have time/energy/resources to learn Rust. Yes it’s somewhat easy to learn, but there are pitfalls to learn to deal with. These types of contributors we lose.
nmeum: It’s a long-time process. Can always reevaluate during that duration – are people picking it up?
Martine: Some people will not learn Rust, so some modules will stay C.

emmanuel: Attractive to Rust community once build-on-Rust possible. Sweet spot. If going for that, in 5y if we want to not have C, we can have Rust-only builds.

Chrysn: On what is RIOT. Apart of community aspect Oleg mentioned (which is probably the best answer), it is implementation? More interfaces. As long as we can provide the RIOT APIs, I think that something like RIOT-rs could still be RIOT. We could cater for different configurations, some fully/predominently Rust based, and some with more C.

Chrysn: 2 questions are: do we want to take this is an call it RIOT? Are we willing adjustments to some API adjustments?

Emmanuel: To support decision-making, on being frightening: Is this something that can give us new impulses in terms of mission and horizon? If so, big plus, beyond the technical aspects.
Martine: Not so much afraid, but fact that we can’t/won’t be able to take everyone in community on path with us.

Oleg: Gotta wrap up.
nmeum: Can learn from Linux kernel. (Which does left thing). Even that already gathers enthusiasm into Linux kernel.
Martine: Yes. Going to right side, we lose people. On the left side, we can still catch enthusiasm.
chrysn: Embedded Rust enthusiasts have “more Rust” OSes to go to. Linux people don’t.

Emmanuel: we already have Rust wrappers, but we have not substantial enthusiasm yet, so maybe we have some shot at trying something more/else

[Yoichi-J Nakaguro, remote]: RIOT developer. Normally use for networking part, currently working on CoAP, evaluating. From that perspective, some thoughts on possible horizon: Not very familiar with hardware part, so can’t catch up with that change in HW layer. […]. Steep learning curve [?]. Currently focussed on networking part. Could be starting in networking layer. Those have no HW specific dependencies. No trouble with that so far. If we consider using more Rust around new devs, maybe start from application/networking.

nmeum: Network stack is what benefits most.
Martine: There we’re on “do we have the ppl”. I don’t have the time to rewrite the stack in Rust.
nmeum: Emmanuel is suggesting more cooperation with smoltcp etc.

Yoichi-J Nakaguro: Don’t need aggressive rewriting; but consider it for new code. For existing, can still bind. Got good experience. Keep C as it is, for new code, consider Rust.

Emmanuel: At INRIA, funding is more available for Rust than for C.

Emmanuel: What Yoichi-J mentioned, we can do that. (chrysn: That’ll be part of the CoAP session anyway)

Leandro: Conclusions?
Emmanuel: Main messages “curiosity about enabling Rust-based config like RIOT-rs”, “doubt about losing people” (chrysn, Martine: not doubt, that’s sure), technical questions (how much C hosted in Rust? i.e. white in 3rd image). Leandro: Usually we start such things w/ motiviation except memory safety and more interaction with Rust communities. Otherwise haven’t heard much about “why?”, needs more elaboration at start of next discussion. (Emmanuel: some arguments in the slides I presented yesterday)
Emmanuel: Of those we lose, who’s in core/sys?
Martine: Several.
Matthias: Speculation.
Martine: Rust somewhat of a current “fashion trend”. Yes it has its objective upsides, but what if there is a new shiny thing in 5 years that has even more objective upsides.
Jose: RDM? Not for document, but for discussion in it.
Emmanuel: (Writing up an draft RDM based on the slides I presented shouldn’t be too difficult.)

Bonus content from the Matrix Chat by Jose :wink::

(I guess this post really belongs here)

I wanted to post about a netdev talk this fall about Rust in the Linux Kernel. The email announcing it was not public in the end. Ah, I found the link: https://netdevconf.org/0x17/sessions/tutorial/rust-for-linux-networking-tutorial.html It’s a tutorial. I don’t know much about the Rust integration into the Linux kernel; the talks at LPC last September was in conflict; I should look it up. I think they did not use cargo, but I am not certain.

I wanted to remote attend all of last week, but due to reasons I didn’t make much of it. I did catch the last 5 minutes of @Kasper’s talk, and I hope to see the video posted.

This is my take on where to go with RIOT-OS + RUST.

  1. We won’t get there overnight.
  2. There is a very big win for having a RIOT crate that just contains all our C code with some reasonable default Kconfig. It’s okay if it uses 80% of the code space on the target platform. The target audience are (new) people writing main() in RUST. I think we had a talk about this from Japan in 2021’s conference. It doesn’t have to be for every platform, just ones that are actually available.
  3. There are many bits of code that would benefit from being written in Rust, even if they call C functions and are called by C-functions. They would ideally be no_std, but really it’s when you need to keep track of some memory that is allocated that RUST wins. The key here (IMHO) is to find a way to just plop .rs files into our tree and have them work.
  4. The work that @j-devel has done is probably more advanced than many are ready for, but OTH, many will get to wanting async runtime for applications very soon.