Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing an OS in Rust: Introduction to Paging

os.phil-opp.com

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Writing an OS in Rust: Introduction to Paging

#51

Post by rixrax »

tormeh wrote: post #24
fermienrico wrote: post #7

Earlier quoted context omitted.

I agree. Wouldn't it be amazing to have a "Handmade Hero" series but for OS development in Rust? That would be incredible. A lot of the OS development, especially esoteric subjects are behind walls of IP control barring Linux kernel. Even then, just reading the source code is different than having access to the knowledge base that enables you to write such a code. I am new to all of this but like you, I am fascinated…

>A lot of the OS development, especially esoteric subjects are behind walls of IP control barring Linux kernel. Join the Redox community! Development is on gitlab[0] and chat is on Mattermost. 0: https://gitlab.redox-os.org/redox-os/

+1! Redox Os (micro kernel Os written in Rust) feels like a gust of fresh air! Godspeed! I am rooting for you!

I don’t know what this says about me but I haven’t been this excited about new OS since I first installed OpenBSD 2.5. :)

Re: Writing an OS in Rust: Introduction to Paging

#52

Post by convolvatron »

simias wrote: post #26
JesseWright wrote: post #2

I've followed Phil's site on making an operating system. Ever since having worked on PintOS in college, operating systems and their internals have fascinated me. I've tried learning more about writing operating systems via resources like the OSdev wiki, but much of its material almost seems to discourage working on an OS of any kind unless you're already sure of what you're doing. Phil's articles seems so much more a…

I think it's one of these things that's more approachable if you start by working on specific subsystems of an existing OS. This way you don't have to figure everything out at once. At least that's how I did it. I think writing an OS from scratch is discouraging and not very accessible because... writing an OS is discouraging and not very accessible. It's a bit as if a painter was saying "It tried looking up guides o…

i dont disagree with you, but there are alot more basic resources available now then when I learned kernel programming in the early 90s.

also, being able to develop under qemu is a massive* timesaver. not only can you reboot completely from the terminal, and have access to a gdb stub, but you can also get tracing information directly from the "hardware" itself.

using the virtio drivers gives you a pretty quick onramp to having network and storage support.

you could* write a 1000 page book on vm...but writing a little interface that builds x84-64 page tables really is a couple hundred lines. interrupts another 1-2 hundred. threads another, syscall dispatch, etc.

I'm not suggesting that everyone go off and build their own production grade private OS.. but its a pretty fun exercise, and it gives you a really great perspective on whats going on down there.

Re: Writing an OS in Rust: Introduction to Paging

#53

Post by Someone »

simias wrote: post #26
JesseWright wrote: post #2

I've followed Phil's site on making an operating system. Ever since having worked on PintOS in college, operating systems and their internals have fascinated me. I've tried learning more about writing operating systems via resources like the OSdev wiki, but much of its material almost seems to discourage working on an OS of any kind unless you're already sure of what you're doing. Phil's articles seems so much more a…

I think it's one of these things that's more approachable if you start by working on specific subsystems of an existing OS. This way you don't have to figure everything out at once. At least that's how I did it. I think writing an OS from scratch is discouraging and not very accessible because... writing an OS is discouraging and not very accessible. It's a bit as if a painter was saying "It tried looking up guides o…

”I think writing an OS from scratch is discouraging and not very accessible”

A lot of work, yes, but, IMO, fairly accessible if you are willing to skip the steps initializing the hardware (“it’s tedious, but luckily somebody did it for us”), don’t aim for replacing the state of the art, and support limited hardware (certainly no USB-C, for example)

For example, your first usable system doesn’t need paging, memory protection, or even a halfway decent memory allocator. You also need not support zillions of different devices (Linus didn't, either, with his first usable system)

Just start with an OS that runs a fixed max number of processes each in some fixed amount of memory in round-robin fashion. Let’s say you have a gig of RAM. Split it in 1024 1 megabyte blocks, reserve one for your OS, and require programs to be position independent.

Yes, that’s almost equal to a single process running multiple threads (in some sense even worse, as a program wanting over a MB of memory can’t run, even if the other processes take only a small fraction of their megabyte or memory) but that’s what makes it accessible. It also isn’t too dissimilar from what was done historically (it isn’t that many steps away from the original model of Windows CE, for example, and that isn’t even 25 years old).

If you have that and a minimalistic file system, you probably can run quite a bit of Linux userland on it (slowly because of the round-robin scheduler, and crashing often when processes run out of memory), but then it’s just a matter of scratching itches as they come up. Memory protection probably would be one of the first features I would add, as it makes the system way more robust. An editor and a (simple, say a single-pass compiler of a pascal-like language) compiler also would be high up, to make the system self-compiling. VM paging probably would come late in the game now that small systems have at least a gig of RAM.

Re: Writing an OS in Rust: Introduction to Paging

#54

Post by vardump »

simias wrote: post #50
anyfoo wrote: post #45

Earlier quoted context omitted.

I agree. By the way, you mention high impedance and metastabilty. Knowing next to nothing about the PlayStation, are those concepts relevant for emulation there for some reason? For other platforms I think that’s an abstraction layer that even accurate emulators rarely hit (though I might be wrong). Is there something special on the PlayStation?

It's been a while since I've looked into it so I hope I won't be too far off the mark: - Regarding high impedance it might be relevant if you want to explain how the controller and memory card interface works, and why you read full 1s when nothing is connected (high impedance line with a pull-up resistor). More generally the issue will crop up every time you have an interface that might be floating, I think people wh…

It's conceivable that metastability issues could be used as a part of copy protection. Well, protection against emulation more like.

Of course it's not the smartest choice for that purpose, because there might be chip-to-chip differences. And environmental factors like temperature could affect it as well.

But who knows what people wrote after Bleem PS1 emulator was public?

So have metastability issues (or other HW bugs) ever been used for copy/emulation protection?

Re: Writing an OS in Rust: Introduction to Paging

#57

Post by phil-opp »

phkahler wrote: post #43

On page tables... Why would they go to 5 levels rather than just increasing the page size and the number of bits in the indexes from 9 to 12 and make each page 32K or 64K?

I assume backwards compatibility. It's a much smaller change to existing operating systems than to create a completely new page table format.

Re: Writing an OS in Rust: Introduction to Paging

#59

Post by anyfoo »

simias wrote: post #50
anyfoo wrote: post #45

Earlier quoted context omitted.

I agree. By the way, you mention high impedance and metastabilty. Knowing next to nothing about the PlayStation, are those concepts relevant for emulation there for some reason? For other platforms I think that’s an abstraction layer that even accurate emulators rarely hit (though I might be wrong). Is there something special on the PlayStation?

It's been a while since I've looked into it so I hope I won't be too far off the mark: - Regarding high impedance it might be relevant if you want to explain how the controller and memory card interface works, and why you read full 1s when nothing is connected (high impedance line with a pull-up resistor). More generally the issue will crop up every time you have an interface that might be floating, I think people wh…

Ah, thanks. Now that you mention it, high impedance data lines ("open bus") do play a role in other platforms as well. Even more so, on the C64 for example some undocumented instructions cause conflicting drivers to drive the same lines and produce randomish/unstable outcomes.

And nice to know that there are indeed metastability issues that crop up very visibly in the PlayStation!

Re: Writing an OS in Rust: Introduction to Paging

#60

Post by db48x »

smrq wrote: post #37
AnIdiotOnTheNet wrote: post #34

Earlier quoted context omitted.

The game is still actively in development. It isn't just a clone of some other game, it's a new game and the actual design of the game is another part of the project that's evolving as the engine is built.

To be honest, I think this is the primary weakness of Handmade Hero. Casey is plainly a more talented programmer than designer, and his missteps in the latter domain felt to me more like wasted time than valuable experience. This is why I stopped watching somewhere between episode 200 and 300.

Backtracking, experimenting, and changing your mind is part of the game development process. No game ever ends up being exactly what the designers imagined at the start.
Post reply on HN