I've been playing with Rust for os dev and emulation for a little bit. It's great to have others who are significantly more well-versed in this field sharing their knowledge with those of us who are struggling through it.
Author here. As steveklabnik says, I'm figuring this out as I go along, with much help from the amazing OSDev wiki: http://wiki.osdev.org/Main_Page
Basically, this stuff is a ton of fun, and I'm just sharing my learning process with other people in hopes that we can all learn from each other and spend less time digging through hardware data books. :-) In particular, I recommend Philipp Oppermann's great introductory posts: http://os.phil-opp.com/ And if you'd like to hack on a somewhat more complete Rust-based OS, the Redox people appear to have gone into overdrive in the last few weeks: https://github.com/redox-os/redox
The #rust-osdev channel on Mozilla IRC is also full of great folks, who've helped me with all kinds of challenges.
On the other hand, i really really would encourage any new developers to read the rust docs before learning c++ etc. It is amazing to have a language that puts its mem model first. The docs tackle the very basics really well.
The k&r c book is amazing but did a poor job of dealing with the true memory model because that was common knowledge at time of writing. Its short because of assumptions
the best java (top 0.01%) developers are the only ones I encounter often who understand the x86 + javas basterdised memory model
The rest just take it for granted. Even c++ developers (I'm one).
I actually doubt Rust puts the memory _model_ first, but it provides a path through which you effectively don't have to worry about it at all. Which is wonderful and good enough, really.
IIRC Rust has a similarly confusing underlying memory model. However, due to a lack of direct shared mutable state being available, you don't get to see this often. In fact, one might call Rust's model more confusing than C++ since you have `noalias` everywhere which can enable more aggressive optimizations. But it's mostly irrelevant since you don't deal with it unless you're writing unsafe code.
On the "encourage new devs to read the Rust docs" front I agree, though. We've had tons of people saying that they code better C++ after learning Rust. Also I've heard of companies wanting to start programming in C++/Rust-y things with a majority of python/ruby/js/etc devs use Rust because "Rust teaches a lot of things to the programmers that they no longer have to". Something like that.
> IIRC Rust has a similarly confusing memory model
In fact I believe that at a fundamental level Rust is forced to more-or-less adopt C11's memory model thanks to its usage of LLVM, though, as you say, Rust's concurrency safety mechanisms mean that the theoretical soundness issues that apply to C11 are toothless in Rust.
Yeah, this is because we want people who may not have a systems backround to be able to use Rust. That's just general info on the concept of stack vs heap, it's not Rust-specific.
I feel far too many books make assumptions that things are "common knowledge". I think they are afraid of putting too much remedial and review stuff at the beginning or in the book in general.
But in reality, the percentage of people who understand something fully at the 'expert' level is very small. Best way to find out if you know something or not is too teach someone else.
This is exactly on point, for any kind of teaching. And reviewing the 'basics' can help situation information in context you already know.
Ironically, I often use a paging metaphor here, for stuff that I learned, but haven't thought about recently... going over something again to refresh my memory is just swapping that page back in.
When the author was writing this post, they said on IRC something like "I've just been reading a ton of manuals, I hope someone more experienced starts writing too."
No - Part of how interrupts work is that the CPU itself pushes the values of certain registers onto the stack (As well as an error code in the case of an exception). The CPU has to store those values somewhere so that when the interrupt is finished it can return to where the CPU was running when the interrupt happened, and the stack is the obvious location to do so. You can't tell the CPU to do anything different in this case, so you're forced to simply make sure your stack pointer always points to the top of the stack so it doesn't get clobbered.
At the end of the day, it's not really that big of a deal - Allowing the redzone only really allows you to avoid two `sub` and `add` instructions on the stack-pointer. It's a nice idea, but losing it isn't that big of a deal at the end of the day. The majority of functions can't take advantage of the red-zone anyway, because any function that calls another function has to make sure its stack-pointer is correct before calling it.
I was wondering, would the monolitic/micro-kernel discussion be different today due to userspace services being able to use all the fancy cpu extensions, or would that still disappear compared to the cost of ring switching? Now that filesystems are more complex databases, maybe extensions could help with fast indexing/checksumming.
