I confess! ;) No, seriously, I'm parroting what was said by the developers on the group some time ago. My understanding at the time was that core allocation library is part of std, so if you get rid of std (which is what you'd do writing OS - things like printing on the screen have no place in kernel) you'd have to recreate this. But I never bothered to dig deeper since OS development is not what I want to use Rust for.

My feeling though is that you need to be able to allocate memory to write code in Rust (duh!) and memory allocation is something that OS provides. So if you write OS in Rust... you get the idea. My understanding of Rust isn't deep enough to state whether you'd have to reimplement internals of Arc, Box and what not or you'd just have to provide something they piggy back on. But there's an explicit assumption in most of the code that you can allocate memory (in a thread safe fashion no less) which isn't there if you have no OS underneath.

It's all good, that's exactly why I was curious. Your understanding isn't exactly wrong, but basically, all that code relies on there being an 'alloc' and 'free' symbol, so you can swap that out with whatever you want, so you wouldn't actually need to re-write all that code. Also worth noting, there's a clear line between libraries with no allocation (libcore) and the rest, so even if you did throw it all away, you'd still have a chunk of the library.

That interface is super unstable at the moment, and we're working on stabilizing it, but yeah, that's what you'd have to do: write your own allocator and hook it up.

Cool, thanks for the details. I guess I should check who's asking before I respond the next time around. ;) It wasn't clear whether you're pulling my leg or you're interested in deep dive I can't provide. But you can. :] So, question then - wasn't it the case (at one point) that you had dependency on stack unwinding library or some external implementation of TLS? My feeling is that what I read about OS development at that point had also something to do with one of these two. Maybe. Unwind is native to Rust right now and is no longer a problem (on platforms supported), no?

:) It's all good, I was a little bit terse... I should consider that in the future.

We do use gcc's unwinding library, last I recall, but if you're writing an OS, you can implement the language items to do whatever you want, including just abort.

There's no inherent TLS implementation that I'm aware of.