Ownership is Theft: Experiences Building an Embedded OS in Rust (2015) [pdf]

Here's one in particular:

    In principal, this would allow us to statically allocate 
    a buffer sized for each particular closure. 

    Unfortunately, there is no size_of keyword in Rust,
    and static initialization cannot invoke functions—
    in this case the function size_of<T>() -> usize provided
    by the Rust core library.

https://github.com/rust-lang-nursery/lazy-static.rs

From the description in the README:

    Using this macro, it is possible to have statics that 
    require code to be executed at runtime in order to be 
    initialized. 

Take this paper with a grain of salt: it's a bit dated at this point, and there are solutions for a number of the problems posed.

For instance in the 'Callback through closures' example, there is code like:

    setTimeout(|| {
      activityLed.toggle();
    }, 2000);

Instead I think the code should be more like the following, which models calculation of new state as a pure function. Side-effects are separated out by storing the desired effect as data, dedicated function for realizing. Time is just data, time-based logic without depending on hidden state.

This increases testability significantly. And it can be fully reasoned about by Rust, no conflicts with the borrow checker.

    # for each tick
    # calculate new state
    if (now >= state.toggleLedTime) {
      state.activityLed = !state.activityLed;
      state.toggleLedTime = now + 2000;
    }
    # and realize it
    updatePin(config.ledPin, state.activityLed);

http://manishearth.github.io/blog/2015/05/17/the-problem-wit... details why it's necessary.

The article does sort of mention this (and I have talked with the authors about this before) but IMO it underrepresents the importance of it.

One thing I did discuss with one of the authors at one point was swapping around the guarantees a bit -- allowing multiple &mut for cases not involving any form of runtime typing (enums and vectors are both cases of runtime typing -- in a vector the number of elements is runtime dependent). This would create a significantly different language and be incompatible with the vast majority of the ecosystem; however, it would still be safe, and has the potential to be useful. I even started hacking on a fork of the compiler that does this, but never got the chance to finish it. The idea in essence is not too hard to implement.

"...embedded platforms are highly event-based, and Rust’s memory safety mechanisms largely presume threads. In our experience developing an operating system for embedded systems in Rust, we have found that Rust’s ownership model prevents otherwise safe resource sharing common in the embedded domain, conflicts with the reality of hardware resources, and hinders using closures for programming asynchronously..."

The problems they mention and run into, have already been examined and dealt with in embedded Schemes, such as BIT, PICBIT and PICOBIT.

PICBIT http://www.iro.umontreal.ca/~feeley/papers/FeeleyDubeSW03.pd... (see the GC section)

PICOBIT http://users.eecs.northwestern.edu/~stamourv/papers/picobit.... (not as relevant in that hard decisions/tradeoffs examined in predecessor PICBIT)

BIT (1995) https://github.com/melvinzhang/bit-scheme

QNX, though usually sends a message to a thread in a process when an interrupt comes in. The interrupt is processed slightly later. QNX has no interrupt lockouts longer than a few microseconds, because it's not doing much from interrupt code except sending messages. QNX also has a strict real-time priority system, so this doesn't hurt interrupt processing latency. So everything running in a thread uses the regular locking mechanisms, rather than depending on interrupt lockout.

Something like that might be a better fit to Rust's locking model. Either that, or the language has to know about interrupts, as in Modula I.

The authors have been meaning to write a follow-up paper describing how they overcame the problems here, but haven't just quite yet. That slightly different design is what became Tock.

Largely unrelated to Rust, but I want to point out that that is a powerful insight. It took me a while to internalize that. Once you see it, you'll understand why asynchronous, callback-based programming is usually inferior to other models (green threads, channel, lightweight processes and yes, threads). There are some exceptions for course, say when callback chains are short, like a web proxy, in the an embedded world, or a short demo code someone pasted on SO.

Another way to think about it is that "an sequence of callbacks forms an ad-hoc execution context, like a thread almost, except it is spread all through various functions, not very well specified, not in one single place".

Now perhaps in this style you can avoid CPU locks, but if callbacks are used for concurrent IO, you are back to the the need to protect global data from concurrent modifications. For example, if a callback chain starts, say cb1, cb2, cb3 but stops at cb2 while it was modifying some global data. Then another user request (or other such event) comes and it starts running cb1, cb2, cb3. It will possibly start modifying the same global data before it was in a consistent state. Next thing you know is you need something like a lock or semaphore. And sure enough such a thing exists, here is an example in Twisted: http://twistedmatrix.com/documents/8.1.0/api/twisted.interne...

No no no. Badly designed GC, for sure. But for any modern, thought-through GC this is not true.

And in any case, the Linux kernel uses ref-counting all over the place, which is the worst form of GC - slow, hard to debug, full of potential places to trip you up and cause a leak or a security bug, ...

[1]: https://tokio.rs/

[2]: https://github.com/alexcrichton/futures-rs

EDIT: In particular: the people behind this recently began offering an IoT development board, "Hail", that runs Tock (the OS from the OP): https://www.tockos.org/blog/2017/introducing-hail/ (discussion on /r/rust, with authors present: https://www.reddit.com/r/rust/comments/61257c/introducing_ha... )

EDIT 2: I see that the title has been updated, thanks. :)

One choice, for example, would be to rely on the bootloader's handling of .bss sections to allocate a temporary 'heap'. Haven't tried it, but it probably gets the job done well enough to bootstrap a real dynamic allocator. The point is, though, you can't just say "throw lazy-static and a custom allocator at the problem". Note, for example, my proposed solution requires writing the custom allocator entirely outside of Rust, since it can't access any Rust statics. It also requires two implementations of the custom allocator - one for bootstrapping, and the other after bootstrapping. These will have to be dynamically selected between at runtime since (AFAIK) Rust is hardly going to support static switching between them. Then you have to consider interoperability between them.

Finally, not all kernel designs are prepared to do any kind of dynamic allocation at all: microkernels which hand all available physical memory to userspace for management there cannot dynamically allocate (except, perhaps, for O(1) of allocation in a small, static heap - but at that point, what's the point?).