This has been posted more than once before, but I thought worth submitting as there’s lots of new content. Fascinating stuff.
I like the tutorial very much, but cannot lose the feeling that at the point of integrating Rust, it’s a huge matter of sneaking around its complexities.
The author seems to be very invested and integrated into Rust development, and I personally lost it when he casually added this “panic-strategy” line to the json-file or where he added the few magic lines to his root source file, which even make #pragma’s look good, in the article “Set Up Rust”. How are you supposed to come up with this unless you know exactly that e.g. Rust is unwinding the target in case of a panic and can deduce it from the chunk of compiler barf slammed on your screen? And this is just an excerpt of quite a few esoteric appearences in this set of articles.
I wouldn’t be able to follow this tutorial, build my own OS and integrate Rust, without fearing that I somehow forgot to disable this or that feature or implication, which could bring everything down once I’m using a certain feature.
Surely the Rust Evangelism Strike Force will teach me right and tell me that knowing about these inner workings is common knowledge, so please forgive me my sins!
I suppose my question is what the alternative is. Low-level programming like this is the realm of arcane magic and strange incantations. Rust, providing the safety mechanisms it does, has to have some facility for turning those mechanisms off, and there has to be careful consideration of the interaction of those mechanisms and the low-level code that circumvents them.
If the question is documentation, there’s little to say other than that things are getting better, and the Rust has only been post-1.0 for a little over two years now. Give it time, and there will be more and better guides and documentation to help navigate the world of low-level programming in Rust. Personally, my hope is that someone publishes a hard-copy book on the topic, with a particular focus on the language of Rust and its use and tricks in low-level programming, and less on the development of a particular system as is seen here.
Tbf, knowing that the stack unwinds on a panic is well-known in Rust. If you think there are any fewer corners in C++…
The tutorial being a bit old, this isn’t even the case anymore necessarily. Rust can be compiled to abort on panic instead.
While I don’t fully agree with the parents angle, they are right in that Rust is a complex language that has ramp-up time to learn.
Hey, not everyone knows everything. Teaching is good, shaming is not.
The ‘Bare bone’ part is very nice introduction about how to start writing x86-64 OS in any language. Other thing I noticed is x86 assembler. I do not have much experience with it, but I noticed that even it is CISC processor (at the end), still it is used in some kind of RISC manner: move some constant to the register and then move it to the other register - look at e.g. enable_paging procedure. I always had an impression that in x86 it could be done as a one assembler instruction.
I think in a lot of cases this is necessitated by the instruction encoding. x86_64 uses 3 or 4 bits to represent a register, which works well for the 16 general-purpose registers, but to access other registers you need separate instructions.
I’ve been following this, and also Steve Klabnik’s Intermezzos project, with interest. However, every single one of these build-your-own-x86-OS tutorials that I’ve seen (including some of the non-Rust ones), seems to only make use of VGA text mode, and not even attempt to draw more complicated graphics to the screen. I’d really like to see a tutorial that goes into the details of how to make VGA draw something interesting to the screen - it can’t be that much more complicated than any of the other esoteric things you have to do to make an OS boot, can it? Or perhaps a version of this tutorial aimed at a format with a modern, well-known graphics chip like the Raspberry Pi would be good.
You might find this site helpful:
Also hints manipulating pixels through BIOS was low-level and really slow.