[RFC] The embedded Rust initiative: Scope

[japaric]

Hello!

I'm a Rustacean that wants to see Rust become a great language and ecosystem for embedded projects (but I'm sure I'm not the only one!).

This repository is an attempt at mobilizing efforts towards that goal and this RFC (rendered) defines the scope and contents of this repository.

I'd love to hear your thoughts about this RFC. Also, I'll soon be opening more issues about the "obstacles" (term defined in the RFC) that I see right now and it'd be great if you can participate in the discussion about those as well.

---

cc-ing people that may be interested. Apologies if you are not! You can unsubscribe from this issue by clicking the unsubscribe button on the right side of this page.

"Arduino" sub-ecosystem

@SimonSapin
@alevy
@cbiffle
@cwoodall
@hackndev

"OpenWRT" sub-ecosystem

@Manishearth (as a proxy 😄. IIRC, you know people who are interested in Rust+OpenWRT)
@kteza1

"Raspberry Pi" sub-ecosystem

@posborne

---

Also, cc @alexcrichton, @aturon and @nikomatsakis. This repository could become a valuable source of information about the needs of embedded developers.

[posborne]

CC @nastevens

[steveklabnik]

One thing that might be pertinent for this RFC is to define how embedded is separate from OS-dev. Or is it? There's some bleed-over, but OS dev on x86 seems to have slightly different needs than these kinds of devices would.

[cbiffle]

A lot of bare metal embedded development looks like kernel development. After all, the reason we have kernels is to bundle up a bunch of commonly used services that we'd otherwise be rolling ourselves.

I also tend to use RTOSes in my embedded work and am specifically interested in using Rust there (I designed Brittle to be eventually rewritten in Rust). This is literally OS-dev and embedded work.

So I think there's a lot of overlap in the sorts of language/library features we are likely to push for.

I do think it's worth separately representing the interest of embedded, as Jorge has done here, because most OS-dev work seems to be happening on either x86 or ARMv7-A processors these days, and in our world we deal with significantly trickier beasts. (24-bit integer DSPs with ones-complement arithmetic, say.)

For similar reasons, I'm not sure I understand the inclusion of OpenWRT here. It's a traditional Linux environment with memory in excess, well-served by existing tools. Is it just because they are also interested in cross-compilation? (RaspPi, on the other hand, is a hardware platform that people are doing bare metal development for.)

[steveklabnik]

I do think it's worth separately representing the interest of embedded

To be clear, I do as well, specifically because it can tease out things like

For similar reasons, I'm not sure I understand the inclusion of OpenWRT here.

I'm not arguing OSdev needs should be rolled into this group, but more clearly defining how this group is different.

[cwoodall]

I think we need to clarify our sub-ecosystems and combine them where necessary:

• arduino/microcontroller: a strictly no_std application. Maybe with some lightweight os maybe just with frameworks going bare metal.
• openwrt I am not very familiar with this level, so I will not comment.
• rpi probably can leverage a lot of std more extends to library support for talking over peripheral interfaces, controlling actuators and reading from sensors. More support for cross-compiling and maybe even leveraging some of the more interface/trait level concepts to make an ecosystem that is familiar between the various levels.

Also, as someone who does embedded systems work in my day job I would appreciate if we develop this community with an eye towards testing/testability, reliability and as a long term goal I would love to see Rust be at the point where it could be used in a medical device, car, etc. It is a lofty goal maybe, but currently we use C and a large portion of our risk factors come from problems rust could in theory solve with its memory safety. (as a side note I wonder if rust could ever provide similar compile time contracts and constraints as SPARK)

[Amanieu]

One of my use cases for Rust is similar to the ones you listed, but doesn't really fit in one of the categories. I plan on using Rust for code which runs under a mainstream OS (eg. Linux) but without linking to libc. The basic idea is that this is code that will be inject into another running process.

Because there is already another process in the address space, the code has to work in a very restricted environment (#[no_std]) and is basically only allowed to use raw syscalls. This is quite a niche use case so I'm not sure if it is worth mentioning here.

[japaric]

One thing that might be pertinent for this RFC is to define how embedded is separate from OS-dev.

It's certainly relevant to this RFC. It's even in the unresolved questions.

The definition of embedded that this document uses is pretty much the one that @cwoodall gave:

embedded development wants to be an application development problem

and

their (a embedded developer's) goal is often to take a processor hooked up to sensors, actuators,
communication devices and make that package do something

Under this definition, a Raspberry Pi running Debian hooked up to a wheeled robot and a camera is an
embedded system and it's the kind of systems that belong in the rpi sub-ecosystem.

Whereas @cbiffle's definition of embedded seems to only include bare-metal development to me.

I think of the devices in openwrt sub-ecosystem, which are mostly routers, as pre-packaged /
non-easily-modifiable embedded systems. And, my main reason for having them in their own category is
that they don't have a "normal" Rust development process as you (a) always have to deal with cross
compilation and (b) have to think about integrating Rust into other build systems that build the
whole Linux rootfs.

[alevy]

I think embedded has at least two specific differences from OS-dev:

1. (More) resource constrained. General-purpose OS dev tends to be for relatively large devices (GBs of memory) whereas even OpenWRT style embedded systems (which I consider on the higher end) have at most 100s of MB.
2. Embedded systems need to be much more customizable. A general-purpose OS tends to go for (more-or-less) one-size-fits-all systems where a particular OS will target basically the same hardware configuration---typically a PCIe bus with a disk/ssd, keyboard, mouse, screen, network, etc. Embedded devices, on the other hand, have more customized hardware and the system that runs on them needs to be easily adaptable to those different configurations. Maybe one platform is only a temperature sensor and an MCU that doesn't have any storage other than the embedded flash, while another one is a WiFi + LCD screen + MCU + a flash card where apps are loaded from.

[alevy]

BTW, this is, of course, mucky rhetorical territory. Many people would consider Android an embedded system because at the end of the day, device vendors have to customize it to their particular chipset and board, while many others (like me) would consider it general-purpose because the majority of the system is basically constant across deployments. Even a browser is kind of an operating system in a certain light.

At the end of the day we're all just playing around with bits instead of getting real jobs, so it's obviously more up to what folks want to focus on.

[posborne]

I think the main cross-cutting concern for "embedded systems" is that of dealing with hardware. The method for interacting with hardware resources can be decomposed into a few basic categories (as I see it). These categories are a little different from what has been previously proposed:

• Userspace Embedded: Typically, this type of hardware control is done within the context of embedded linux systems, but it could apply for FreeBSD or other OS's. The common characteristc for this category is that access to hardware is done via a well-defined, cross-hardware manner via kernel APIs. The interface here looks the same if the target system has a lot of resources or only a few. The std crate is usually an option in these environments.
• Bare Metal/RTOS Embedded: In these systems, hardware control typically involves more direct interaction with hardware registers in order to control hardware. Although some APIs may be present systems in this space typically need to define both the hardware abstraction layer as well as the application logic built on that HAL.
• Embedded Kernel: Between these two worlds is the world of kernel development. Part of the job of a kernel has to do with defining abstractions for controlling hardware and in that sense it is very different from embedded development. Kernels will not typically define the application logic and in that sense are different than many complete embedded solutions. Sufficiently large bare metal projects frequently start to look very much like kernel development projects at some level.

Much of the work I have done professionally has been in the userspace embedded (in Rust and other languages) and Linux kernel development (no Rust OS dev for me yet). I have done some work on bare metal (including work on Zinc) as well.

From my perspective I don't think the differences between distros like debian/fedora on a RPi and things like OpenWRT/Yocto on custom hardware are too relevant to the language story for rust embedded. There are important projects that need to go on to make Rust easier in various environments (e.g. https://github.com/meta-rust/meta-rust / https://github.com/rust-embedded/meta-rust-bin) but that concern seems orthogonal.

[nikomatsakis]

cc @jcsoo -- I think this would interest you.

[cbiffle]

I kind of agree with @alevy about the risk of getting lost in semantic weeds here. I did not intend (as @japaric noted) to include only bare-metal, since I tend to use an RTOS.

Let me approach this from a different direction: here are some classes of programs that may be worth our consideration. This is not intended to be exhaustive.

• Programs that do not use dynamic memory allocation. This is one of the main reasons for me going no_std. In particular, if you'd like to allocate all objects of nontrivial size statically, and reason about when they get initialized, this is currently very manual in Rust (without codegen).
• Programs that operate in very resource-constrained environments. Think 128 bytes - 4 kibibytes of RAM. Rust actually seems well-suited for these environments, but its libraries are not. (This is separate from the use of dynamic memory allocation; you certainly can use a heap in 128 bytes of RAM, and hard-real-time applications with megabytes of memory may choose not to use a heap.)
• Programs that directly control hardware, i.e. through memory-mapped registers (ARM, PCI) or I/O space accesses (x86, AVR), as opposed to through a kernel interface. This creates interesting interactions with the linker (to place things at particular addresses), makes things like volatile and volatile-atomic semantics more important, and raises the specter of packed bitfields in registers (a distinct problem from e.g. packed bitfields in network packet buffers, because atomicity of access matters).
• Programs that indirectly control hardware, e.g. a robot controller running on ROS on RaspPi using kernel drivers. I can't speak to its implications on the language/libraries because, to me, this seems relatively well-supported by existing language/code.
• Programs that, for performance or application reasons, are particularly intimate with the processor. For example, the entry point in my minimal embedded Rust demo is the processor's vector table, rather than main -- common in bare metal applications and only weakly supported by Rust/Cargo (like interrupt handlers in general). Or, programs that rely heavily on inline ASM or intrinsics to squeeze every last drop of performance out of a relatively weak CPU (e.g. heavy use of Cortex-M4 integer SIMD in my demoscene code). Also, as @steveklabnik cited, the x86 boot process recapitulating phylogeny.
• Programs that need to be built in a large number of configurations concurrently. This is related to the config problem @alevy noted. The firmware build on my last professional project produced something like 30 binaries, from overlapping subsets of the codebase, for several processor architectures. Rust/Cargo do not support this well today (though simply having #[cfg] is a good start). (To be fair, few systems do well here. I had to write my own build system to get reasonable build times and correct incremental builds.)

Finally, I would like to call attention to this:

Having to rely on unstable features in Rust currently makes hermetic, reproduceable builds difficult. The need to use nightly and the inability to pin a toolchain version in the project configuration means that two developers, or even two clones on a single developer machine, can produce different output. Some of this problem will go away as the features we need stabilize. Some of it could be addressed through different tools (e.g. a multirust that respects checked-in version overrides in the project directory).

[japaric]

Thanks @posborne. I found your comment, and also the others, very insightful.

is that of dealing with hardware

I feel that this is key here. But feel that we should go a step further and say "dealing with hardware as directly as the underlying kernel/OS (if any at all) allows" so high-level things like "using TCP" can be filtered even though they ultimately also "dealt with hardware" (e.g. an Ethernet port).

I also want to point out something I realized which seems obvious now: You can write "non-embedded" Rust programs targeted for embedded systems. A good example is writing daemons/services for OpenWRT devices, which I believe is or would be the typical use case of Rust, that don't deal directly with "hardware" but instead use high level abstractions like unix sockets.

I think it ultimately boils down to whether we want to focus on "Rust on embedded systems" or "embedded development with Rust".

Oh, and I haven't addressed OSdev up there but I think that "embedded" ultimate goal are applications (but writing libraries, say a HAL, for those applications is also embedded development IMO) whereas OS dev is about, well, writing OS services.

Given that OSdev also involves dealing directly with hardware (at its lower layers?), the question would be if their problems are similar enough to the ones of embedded developers so we can all share this medium. I feel that ("traditional" x86/ARMv7-A) OS devs should be allowed to participate here but their OSdev specific problems, I don't what those are, should be discussed elsewhere.

I don't think the differences between distros like debian/fedora on a RPi and things like
OpenWRT/Yocto on custom hardware are too relevant to the language story for rust embedded.

I tend to agree. What does feel relevant is that typical OpenWRT/Yocto devices have small memory footprints and still want use the std crate so they want first-class dynamic linking of Rust programs to reduce binary size. That, dynamic linking, is relevant to the language story.

IOW: Yes, it doesn't matter whether they run OpenWRT or Debian because both use share same Linux API but I still find useful to separate these "userspace embedded" devices in two as the ones in the low-end don't face the same problems as the ones on the high-end.

[japaric]

@cbiffle That's an interesting approach. Perhaps we can define the scope in terms of the scenarios developers usually deal with rather than in terms of the devices developers may target.

Here's how the scenarios you described fit in the scope defined in the RFC and on which category they fit:

• Programs that do not use dynamic memory allocation. arduino
  • (I'm assuming that by "program" you mean everything that runs on the target device.)
• Programs that operate in very resource-constrained environments. arduino
• Programs that directly control hardware. arduino (and OSdev?)
• Programs that indirectly control hardware. openwrt, rpi
  • Even if this currently supported by the language, I think it's worthwhile to discuss and compare the abstractions, like traits/API, that "userspace embedded" devs used with the ones that "bare-metal embedded" devs use.
• Programs that, for performance or application reasons, are particularly intimate with the processor. arduino (and OSdev?)
• Programs that need to be built in a large number of configurations concurrently. arduino and openwrt (*)
  • (*) But, they have to deal with re-building the whole distribution (kernel and userspace programs) so Rust has to fit in their more general build systems. And their configuration is mostly compiler flags and kernel configuration, I think.

It'd be interesting to know if the x86/ARMv7-A OS devs also face scenarios similar to the ones you listed.

[cbiffle]

@japaric

I'm using the term "program" quite generically, deliberately, to describe a computer program. This might be a kernel, application, driver, loadable module, etc.

Many OS kernels also choose to avoid dynamic memory allocation for predictability under load. (RTOSes like Integrity, but also systems like L4/seL4.) As do many avionics systems, for the same reason. In cases where it's avoided for principled reasons it usually is due to real-time constraints; some shops avoid it for other reasons.

OS drivers tend to directly control hardware, as do some userland applications (e.g. through /dev/kmem on Linux) and applications written for in-kernel frameworks like RTLinux. I don't really put "writing a Linux kernel driver" into the same bucket as "developing a new kernel," but that might be my own bias.

The other class of application that often avoids dynamic memory allocation and has an intimate relationship with the processor is games. The requirements of a high-end game have a lot in common with real-time embedded applications, and we will probably wind up aligning with the game community on some of our desires.

Neither arduino nor openwrt capture my build case well. OpenWRT builds the entire distro for a single architecture (I have used it on projects). Arduino tends to target simple applications. I'm more referring to firmware builds for distributed embedded systems of 10+ processors. This includes many avionics and automotive systems, but also more mundane cases like the embedded controller networks in your laptop or phone.

I'd be careful using arduino as a label, because Arduino is missing some things (many of the programs I'm talking about run on an OS and have hard-real-time requirements) and implies some things I don't think you intend (like beginner-friendly). I don't have a better name to suggest yet, but I think looking at the use cases and working backwards might lead to one.

[nastevens]

There's already been a lot of good discussion of the different types of qualifiers for what make an embedded system from @posborne and @cbiffle, but one thing that I haven't seen yet is concrete recommendations for naming sub-ecosystems. I would like to propose the following: utilize a "tag" system as opposed to over-arching categories. There are always going to be designs that include multiple characteristics. For example, a hardware driver may utilize the heap or it may not. Or it may provide a hardware abstraction layer or it may not. Using tags means that multiple characteristics may apply to a piece of code.

Here are my proposed tags, open for some serious bikeshedding:

• hardware: Code that provides access to a hardware device.
• low_memory: Code written in such a way as to use a minimal amount of memory, or is otherwise usable on resource constrained devices.
• linux: Code specific to Linux, such as interfaces to Linux userspace devices.
• freertos / vxworks ...: Tags for specific RTOSs
• posix: Code that relies on the generic POSIX interface, but not on specific Linux/FreeBSD/etc. interfaces
• no_std: Code written without the use of the Rust standard library, i.e. it does not use a heap.
• arm / x86 / avr...: Tags for code that is intimate with one or more particular processor architectures.
• build: Code that is not meant to run on the target, but rather supports building on embedded targets. For example, the meta-rust layer for Yocto.

As an application of the tag system's use:

• The sysfs-gpio library would be tagged with hardware, linux.
• The fixedvec library would be tagged with just no_std.

I doubt I have captured all the possibilities above, and would love to hear other ideas.

[nastevens]

On a separate topic: @posborne and I have been maintaining the rust-embedded org on GitHub. I think that this initiative would be a great fit for that org if other people are interested. We are open to adding other admins as appropriate.

On the PR front, I have purchased rust-embedded.org, rust-embedded.com, and areweembeddedyet.com. Right now all three point to a parking page on github.io. If someone with some web development chops was interested in putting something on those, that'd be great! This could also be an opportunity for another RFC defining what content we'd like on those pages (blogs, how-tos, link rolls, etc).

Note: the DNS records don't seem to have propagated yet for the new domains... hopefully by the time you're reading this the links are active!

[jcsoo]

Lots of great discussion here! I've been spending a lot of time recently working on something like this in the IoT space, and getting Rust to the point where it is a viable choice (and someday the preferred choice) on the device side seems hugely important.

I'll offer up a slightly different perspective focused a bit more on the different parts of the community that are impacted.

Language - These are improvements and changes to the core language that are especially important to embedded environments - for instance, the ongoing discussions on memory allocation, intrinsics / volatile, code generation for floating point environments, etc. There should be a place where the embedded community can see what's going on in the various RFCs and collaborate on proposing, shepherding, and implementing them.

Tooling - There is an enormous amount of tooling that needs to be developed and integrated so that the experience of developing in Rust is as good as or better than any other language environment. This in itself is really two related sub-problems: for existing Rust developers, it should be as easy to target and deploy to embedded platforms as it is to desktop / server platforms, and for existing embedded developers, it should be as easy to use Rust as it is to use C / C++.

Libraries - A lot of discussion has been focused here because everybody wants to use well-designed, well-implemented and well-tested code instead of writing things from scratch. Here I again see two related sub-problems: first is making sure that there are great low-level libraries of the type needed for embedded applications (e.g. hardware access, filesystems, network stacks), but also making sure that enough general-purpose libraries (e.g. data structure, crypto and high-level network protocols) are implemented such that they can be used successfully in constrained environments.

Runtime - This area includes everything from simple platform-specific bare-metal frameworks to multi-platform RTOSs to Linux-based environments of varying complexity to other open source and commercial operating systems. Often this is the first and biggest decision to make after the choice of hardware platform.

There's definitely some amount of overlap between these different areas - for instance, Runtime can't be completely separated from Libraries and Tooling. However it seems to me that for the most part these groups are distinct and require different approaches and people, and within each area there is plenty of room to identify and prioritize specific goals.

Feedback appreciated!

[SimonSapin]

Even though it’s very popular and recognizable I’d prefer to avoid using the term "Arduino" as synonymous to micro-controllers. This name can refer to a company, a trademark, an IDE, a family of hardware, a physical layout of pins compatible with such hardware, a C/C++ API, an implementation of this API, and/or libraries that depend on this API.

In any given micro-controller project, only some of these or maybe none of these might be relevant.

[cwoodall]

I'd be careful using arduino as a label, because Arduino is missing some things (many of the programs I'm talking about run on an OS and have hard-real-time requirements) and implies some things I don't think you intend (like beginner-friendly). I don't have a better name to suggest yet, but I think looking at the use cases and working backwards might lead to one.

I agree with this 100% @cbiffle and @SimonSapin

Some suggestions for alternative labels

• microcontroller: I think it is general and broad enough to include both an Arduino/Wiring like framework (which I think would be a nice goal to help encourage hobby adoption), but also more serious applications, frameworks and RTOSes. The main drawback here is that it is sometimes confusing the difference between a microcontroller and a microprocessor/application level processor and the differences are becoming less obvious every day. I mean someone could develop in this environment with a ARM Cortex-A processor, quark, etc.
• baremetal: Not quite broad enough to include the RTOS case, which might be used at this level of label. Or maybe not? Maybe we do need to differentiate between rtos level and baremetal level. It doesn't have the same vagueness issues as microcontroller, but I think microcontroller might portray the intent better.

[alevy]

I think microcontroller is absolutely correct and not ambiguous: it's limited in memory to on-board SRAM and doesn't have an MMU, anything that uses DRAM and has virtual memory is an "application-level" processor.

[cbiffle]

I generally agree with the recent comments above and I'm really pleased with this discussion so far! @nastevens 's tags seem descriptive and reasonable. @jcsoo 's areas also seem appropriately descriptive. I think we should forge ahead using terms like this to discuss what we are doing without necessarily limiting our approach.

I might suggest that we also consider, and perhaps enumerate in a doc, "allies" in non-embedded fields who are likely to be pushing on the same parts of the language/runtime/ecosystem as we are. For example, game developers, and non-embedded OSdev.

Nit: @alevy , virtual memory usually distinguishes an application-level processor, but external memory shouldn't. I'm personally not convinced that "microcontroller" is descriptive enough to serve as anything other than a placeholder in discussion -- i.e. we should not be making decisions based on whether something makes sense or does not make sense for a "microcontroller." It is more precise than "arduino" though.

[japaric]

@nastevens

I like the idea of using tags. I think it makes a lot of sense to use them for the issue tracker and also to categorize crates. But, IMO, for documentation having a larger category like "Arduino" "micro-controller" feels more appropriate so I think we still try to come up with names for these bigger categories.

As for the tags themselves I like most of the ones you have listed except for low-memory (and no_std, but more on that later). I'd prefer something like resource-constrained, low-resources or resource-conscious as they are more general terms. Later, we'll probably want to create more tags like no-heap, mmu-less and low-ram that sit "below" this low-resources category.

That brings me to the next point: If we are going to use a more rich tag system, we should group some related labels. For example, arm, x86 and avr are all related as they are architectures. We could adopt a system like the one rust-lang/rust uses which is to group related tags/labels by prepending an uppercase letter to their names. Our tags would become A-arm, A-x86 and A-avr where the A stand for Architecture and R-no-heap, R-mmu-less and R-low-ram where the R stands for Resource. If do it that way, let's please document properly what each uppercase letter stands for.

Also, about this:

no_std: Code written without the use of the Rust standard library, i.e. it does not use a heap.

I think no_std shouldn't be conflated with no-heap, you can use the heap without using std but you have to bring your own allocator. To me, no_std could either mean "standard OS" interfaces are not available for this target or no "standard OS" interfaces are used in this crate. Where "standard OS" interfaces are the interfaces that every general purpose OS offers: file, threads, processes, networking, etc.

I have opened #11 to discuss this idea of a richer tag system. Please comment over there to reduce the volume of comments in this thread.

[japaric]

@jcsoo

I think your idea of Language, Tooling, Libraries and Runtime can be integrated with @nastevens
richer tag system. Some interesting I noticed about the categories you mention:

Language issues are always "upstream" issues.

Tooling issues can either by "upstream" (e.g. Cargo) but can also be "community" issues like svd2rust (#10)

but also making sure that enough general-purpose libraries (e.g. data structure, crypto and high-level network protocols) are implemented such that they can be used successfully in constrained environments.

This is interesting. We must not only concern ourselves with crates that we, as the embedded community, create but also about being able to integrate crates from the general Rust ecosystem. This last part could be a simple as this crate just needs an extra #[no_std] attribute or as complicated as this crate needs a new Cargo feature to work without heap allocation.

Also, I'm wondering what should we call these issues about integrating with crates from the general Rust ecosystem. They don't quite fit in community issues.

However it seems to me that for the most part these groups are distinct and require different approaches and people, and within each area there is plenty of room to identify and prioritize specific goals.

Right, this sounds like we should have/form teams focused on these different areas; just like the Rust teams. Some of these teams will have to work more closely with the Rust teams, for example our
team focused on language changes.

[japaric]

@nastevens

re: rust-embedded org. I'm favor of moving this repo under the org though I'm not quite sure what to
name it once it's moved. embedded-rust/discussion?, embedded-rust/issues?

Another advantage of having an org is that we can create teams around specific issues like tooling,
libraries, or particular architectures. If we can make good use of them in the future.

Is everyone else in favor of moving this repo? You can just 👍 this comment.

[posborne]

I'm not quite sure what to name it once it's moved. embedded-rust/discussion?, embedded-rust/issues?

embedded-rust/rfcs might be another option.

[japaric]

Is everyone else in favor of moving this repo?

OK, seems everyone's on board, or at least nobody has raised any concern so let's go ahead with this.

@posborne do I just hand this repo to @rust-embedded and then you take it from there (the rename to rfcs and so on)?

[posborne]

@posborne do I just hand this repo to @rust-embedded and then you take it from there (the rename to rfcs and so on)?

Hi @japaric I have sent you an invite to the org as a co-owner. Once you accept, this should allow you to move the repository under the settings for this repository to the new location. That will retain watcher, move everything, add redirects, etc.

Strictly speaking, adding you as an owner on rust-embedded isn't necessary for this process, but I think it makes sense. Welcome to the core team. We are of course open to moving other repos here and adding other core team members as makes sense.

https://help.github.com/articles/transferring-a-repository-owned-by-your-personal-account/

[japaric]

Thanks, @posborne.

I've moved the repo and renamed it to rust-embedded/rfcs. I've also created a @rust-embedded/rfcs-team; I'm the only member for now but I hope we'll have more members in the future.

[japaric]

Announcement: I've created a #rust-embedded channel on Mozilla's IRC network. Join us! (if gitter's not your thing)

[thejpster]

I just wanted jump on and quickly say thanks to @japaric for the invite. I'm very keen to help out - my end goal is to stop using C for writing embedded code at work and currently that's a difficult sell.

[cwoodall]

Hope this doesn't count as spam, but as new information becomes available for rust on embedded I invite everyone to contribute to this awesome-list! I hope it will promote people just looking for tools to take a serious look at rust on embedded and maybe also act as a way to guide people towards some of the high quality resources out there as they are developed!

https://github.com/embedded-boston/awesome-embedded-systems#rust

[vitiral]

Wow, this was opened only 8 months ago and the landscape has changed dramatically. Should this RFC be revised?

[jamesmunns]

I think we can safely close this PR, as it has been superseded. Closing this PR, please let me know if anyone would like it reopened.