Writing an OS in Rust - Part 9 - Paging Implementation

This is my version of Philipp Oppermann's "BlogOS". It's a baremetal operating system that can boot off of a USB stick on any BIOS-compatible machine, which is pretty amazing. I'm going to be following the whole blog, one video at a time, and running the OS using QEMU instead of booting a physical machine. Just to keep things simple.

Today we actually start looking at page table structures and learn how to walk our way through them. We also allocate our very first page table frame!

#rust #rustos #blogos #rustlang

[timicesq]

10:59 The whole point of the various mapping techniques is to speed up the translation process (it's not exactly fast) and/or conserve memory.

The recursive mapping, for example, lets you sacrifice some of the virtual address space (which on x86-64 you have plenty of) to conserve some physical memory (in the case you have little of it). Precisely it lets you shrink the page tables 512-fold (or, in other words, a reduction by 99.8%), which is or isn't a big deal depending on how much physical memory you have. On full-blown desktops with tens or hundreds of GBs it doesn't matter, but on memory-limited devices, like some low-end SBCs (Raspberry Pi and the like) it may matter.

All those various techniques, all those paragraphs don't matter at all if you're running your OS on a high-end machine with lots of RAM and lots of CPU power.

[jhuyt-]

This video series is incredible! I knew essentially nothing about rust and how to implement these low-level kernel features, and now I know some more :)

Regarding continuous vs. contiguous: I am not a native English speaker, and before looking it up I treated them essentially as synonyms. I did look it up just now and they still seem like synonyms to me. The internet tells me that if you want to be super pretentious contiguous implies that all parts touch. Anyway, thanks for the videos.

[timicesq]

1:03:01 This is **MUCH** easier to follow if you write the virtual addresses in their binary form, split the bits per each page level, and then write the split bits as decimal indices into each level's page table.

Otherwise it's almost impossible to understand why we need a new table and therefore why we need an additional physical frame for that new table.

[chemistrymickey]

Rust question at 30:00:
- Why is it necessary to get a reference to a dereferenced pointer? Is that not just a pointer? I understand that de-referencing a raw pointer is unsafe in Rust, but I would imagine that the unsafe part is the use of the pointer (like in the `l3_table` iteration), not the re-assigning of the pointer from `ptr` to `l3_table`. Right? (sorry, long time C, short time Rust user)