
Writing an OS in Rust: Allocating Frames - ingve
http://os.phil-opp.com/allocating-frames.html
======
steveklabnik
This series has been really great. It's significantly more accessible than
many other OS dev tutorials I've read in the past. I spent all day yesterday
with a friend and the first few posts, it was such a good time. Nothing like
seeing a machine boot up and print something, and know that you wrote 100% of
the source code that makes it happen. Even with a tutorial, it's magic.

~~~
curiousGambler
In case anyone is interested, the best OS tutorial I've ever found is here:
[http://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/...](http://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/os-
dev.pdf)

I've never been able to find a finished copy, but this one definitely gives
you a good start, if only for 32 bit archs.

In any case, I'm pumped to try out this Rust one- looks very well done, and
it's finally an excuse to learn some Rust!

~~~
steveklabnik
It also takes you through the 32 -> 64 bit trampoline, which is nice, given
your previous source. :)

------
shmerl
So basically you can't use standard library memory logic for that?

Somewhat related topic I found:
[https://www.reddit.com/r/rust/comments/2mthq2/how_would_a_ru...](https://www.reddit.com/r/rust/comments/2mthq2/how_would_a_rust_application_be_able_to_properly/)

~~~
fancy_pantser
Right, because the stdlib calls out to C/C++'s malloc/calloc/realloc/free
implementations. Their allocators ask the kernel for memory which, in this
case, doesn't exist yet because we're starting from bare metal.

~~~
shepmaster
This may not be universally true. The Rust docs[1] point out that as of today,
compiled binaries use either jemalloc[2] or the system allocator:

> Binaries generated by the compiler will use `alloc_jemalloc` by default
> (where available). [...] Dynamic and static libraries, however, will use
> `alloc_system` by default.

[1]: [https://doc.rust-lang.org/nightly/book/custom-
allocators.htm...](https://doc.rust-lang.org/nightly/book/custom-
allocators.html)

[2]: [http://www.canonware.com/jemalloc/](http://www.canonware.com/jemalloc/)

~~~
frozenport
That sounds like a deployment nightmare! Does that mean if you return a
pointer from a dynamic library you can't free it in a static library, because
they were actually using two allocation systems?

~~~
Gankro
Rust automatically chooses the "best" strategy based on how you're building
the source, per [https://github.com/rust-
lang/rfcs/blob/master/text/1183-swap...](https://github.com/rust-
lang/rfcs/blob/master/text/1183-swap-out-jemalloc.md)

If you're building a dynamic or static library, we use the system allocator
because Rust is "subordinate". If you're building a binary, we use jemalloc
because Rust is in control and jemalloc is basically the best allocator in
town. These behaviors can be manually overridden, and you can also provide
your own custom global allocator (see linked RFC for details).

A Rust project using Rust libraries will generally link them in as rlibs,
which is basically the Rust equivalent of an object file. rlibs just inherit
whatever allocator from what they're linked into.

