Alloc implementation

[dcz-self]

I've noticed that there are some mentions of alloc in the commit history and the README, but there isn't actually an "alloc" feature.

Is there some version in the works that needs help?

[jrvanwhy]

Regarding the README, it needs a rewrite: #398.

I haven't gotten around to implementing allocation support yet. I was planning to add a separate memory allocation crate, and add a hook to libtock_runtime to initialize it (or another allocation crate -- they should be pluggable) at startup. See the second half of this TODO.

The integration testing infrastructure is a higher priority for me, so it will be a while before I have the time to implement dynamic memory allocation. If you want to implement it, go ahead, and I'm happy to discuss designs further.

[dcz-self]

While I'm getting by on ArrayVec for now, could you point out some resources for whoever ends up implementing it?

From what I've gathered, allocation has something to do with memop, but I wasn't able to figure out which exactly from libtock-c (one of the break setting commands?). Something about interfacing the alloc code with Rust would be helpful as well.

While that information is probably more-or-less searchable, if you had any links at hand, it would help as a shortcut for whoever ends up actually working on allocation.

[jrvanwhy]

The memory layout for a libtock_runtime-based process is defined in libtock_layout.ld. It matches this diagram: https://github.com/tock/tock/blob/master/doc/processram.png

I recommend the following steps:

1. Add a function to libtock_runtime that provides the address of _heap_start, so the allocator can query where its memory starts.
2. Add a feature to libtock_runtime (called something like alloc_init) that makes it call an extern allocator initialization function, and have it pass in the heap's start address.

That should allow you to implement the allocator in separate crates that depend on libtock_runtime. You'll probably want to implement two crates: one that is unit tested but doesn't depend on libtock_runtime, and a separate one that depends it and libtock_runtime and connects them together.

To request more memory from the kernel, the allocator should increase the heap break (which sets the upper boundary of the memory that is accessible to the process) using memop. To return memory, decrease the break. Don't drop it below the start of heap memory, or the app can fault (because it would lose access to global variables).

I don't really have advice on interfacing with Rust's alloc crate, other than I know that setting a global allocator requires using an unstable feature to define error handling logic.