I've been following along while building an armv7a kernel and I really like how you go back and refactor old parts to match newer rust features like your change to using cargo instead of a makefile and inlining asm files into the rust binary.<p>My only criticism is that sometimes there's parts in your tutorial that are missing but present in your os. When going through chapter 3/4 I think you skipped over explaining your kmalloc implementation. It's fine that you do since I feel your tutorial should be more about navigating embedded rust than learning os basics, but a note about this task being implemented at some point would've helped.
I'd like to see a clone of the QNX kernel, which is very tiny, implemented in Rust. It has no drivers or file systems in kernel space; those are all user processes. But it offers a POSIX-like API. Unlike L4, you don't have to run another OS on top of it to do anything.<p>This would be good for embedded applications on Raspberry Pi sized machines, where the Arduino environment is too weak and Linux is too much.
Is there a significant limitation in using Rust on the stable branch? Every interesting tutorial, book, or tool I find seems to use nightly. I know it shouldn't be a big deal but it "feels dirty" and perhaps I should just view nightly as any other language's "stable".
This looks awesome! Yesterday I just started another OS rust walk through and now I have a hard choice between that and this.<p>Any thoughts on this[1] walkthrough in comparison? This one looks more explicitly up to date.<p>[1] <a href="https://os.phil-opp.com/" rel="nofollow">https://os.phil-opp.com/</a>
I had a question of the about a passage under the section:
"Our OS's Filesystem Read Process" where the author states:<p>>"Recall that the block driver makes a request and sends it off to the block device. The block device services the request and then sends an interrupt when it's finished. We don't really know when that interrupt will come, and we can't wait around for it. This is why I decided to make the file system reader a kernel process. We can put this kernel process in the waiting state so it won't be scheduled until the interrupt is received from the block device"<p>Then further down:
>"Now, when we handle the block device's interrupt, we have to match the watcher and awaken it."<p>Is the watcher here similar to the filesystem driver at the VFS layer in Linux i.e the ext4/xfs etc? I believe this is how Linux handles it - the file system driver creates a block IO request and hands it off to the actual block device driver and when the block device driver get's invoked on an interrupt from the disk the block device driver informs the filesystem driver that the IO request is now complete correct?
The minix fs seems to be basically the classic Unix FS design, like UFS/FFS or Ext2, prior to the concept of cylinder groups (at least, per this description and Wikipedia's) and without some of the more advanced features of those filesystems (softupdates, directory trees, etc).
This is awesome. I've been following along for a while, so please keep it up.<p>I wish someday we'll get something like the ESP32 boards but with RISCV.