Hacker News Reader

Comment by Animats | Hacker News Reader

"although it might have been easier to write a small trampoline in assembler code that calls into Rust code."

That's what he did; it's just embedded inside Rust code.

This is the easy part - capturing exceptions. Handling them, and returning control with the machine state intact, is the messy part.

(It's late to be writing an operating system with demand paging. The most paging ever accomplishes is the illusion of 2X the RAM. RAM is cheap today. The price you pay for paging is random large delays in your program. Is it worth it to save some RAM cost? Mobile devices and real-time OSs don't demand-page.)

View on HN

> That's what he did; it's just embedded inside Rust code

The interrupt handler is a naked Rust function (really cool language feature btw), not an assembly trampoline. There may be a line or two of inline asm in there.

This is probably more educational and experimental than doing it with asm like every other OS project does. I thoroughly enjoyed reading about it.

On-demand paging is still relevant, it's used for mmap and memory mapped GPU buffers, etc. Plain old swap areas may be a thing of the past, though.

> This is the easy part - capturing exceptions. Handling them, and returning control with the machine state intact, is the messy part.

Yeah, I plan to tackle this in the next post: Compiling without red zone, saving/restoring all relevant registers, and disabling SSE instructions in the kernel to speed things up.

> (It's late to be writing an operating system with demand paging. The most paging ever accomplishes is the illusion of 2X the RAM. RAM is cheap today. The price you pay for paging is random large delays in your program. Is it worth it to save some RAM cost? Mobile devices and real-time OSs don't demand-page.)

I'm not sure if I really want to implement demand paging, I've just used it as an example. In the next post we will only implement lazy page mapping, so that we no longer need to preinitialize the complete kernel heap.

I would guess that paging could be used for other purposes though, such as compression of inactive application memory.

I worked with an embedded phone OS once where the entire realtime OS ran as a single task in an L4 microkernel.

This was to allow the realtime OS to run in a demand paged environment: if the OS accessed an address from the area defined as 'rom', L4 would allocate a page of RAM and populate it from flash.

The whole purpose of this was solely to allow them to use a cheap NAND flash chip rather than a NOR flash chip (NOR flash can be memory mapped, NAND can't). That was the only thing they used L4 for. Everything else operating-system-wise was done by the embedded OS, device drivers and all.

Surprisingly, it actually worked. (The rest of the OS was a horrible trainwreck, but not this bit.)

> I'm not sure if I really want to implement demand paging

Yes, you probably should. It's the quintessential example of using virtual memory and handling page faults so you probably want to do it just for the educational value (although that would need a disk driver too).

But it's also the key to implementing various modern operating system tricks, such as memory mapped files and dynamically expanding (and contracting) stack (for userspace processes, kernels typically don't do this AFAIK).

What you probably do not want to do is old-fashioned swap space on disk. It's not as useful as it once was because we have A LOT of memory these days and it might be harmful for SSD wear. For implementing this, you'd also need to have some kind of LRU cache to figure out which pages can be swapped out (quite typically in applications like this, swapping in is the easy part, figuring out what to swap out is more difficult).

> What you probably do not want to do is old-fashioned swap space on disk

Yeah, that's what I meant. I definitely plan to use the various lazy loading tricks for mmaped files, loading executables, etc. But first we need a disk driver :D.

One advantage of not supporting paging is that it gets the disk driver and file system out of the kernel. They're not needed early. You need a boot loader that can load the OS and process images, so the OS starts with some processes running. The disk driver (if any) comes in that way, rather than as part of the kernel.

QNX works like this. It's convenient for embedded systems, where you may have no disk at all, ROM, flash, or a hard disk.

Reply on news.ycombinator.com