<story><title>Writing an OS in Rust: Introduction to Paging</title><url>https://os.phil-opp.com/paging-introduction/</url></story><parent_chain><item><author>simias</author><text>I think it&amp;#x27;s one of these things that&amp;#x27;s more approachable if you start by working on specific subsystems of an existing OS. This way you don&amp;#x27;t have to figure everything out at once. At least that&amp;#x27;s how I did it.&lt;p&gt;I think writing an OS from scratch is discouraging and not very accessible because... writing an OS is discouraging and not very accessible. It&amp;#x27;s a bit as if a painter was saying &amp;quot;It tried looking up guides on how to paint The Wedding Feast at Cana but they all make it look super difficult, I wish I could get an easy step-by-step tutorial&amp;quot;. Even if you break it down in small, digestible parts I&amp;#x27;d wager that you&amp;#x27;ll end up with a few hundred episodes before you even get a basic microkernel up and running on a modern system. It&amp;#x27;s truly a daunting task.&lt;p&gt;I learned that the hard way: I tried to write a guide on how to emulate a PlayStation from scratch. At first you focus on emulating the instructions in the CPU, that&amp;#x27;s relatively focused and straightforward. But then once you&amp;#x27;re done with that you need to explain the various peripherals, and the main bus, and the interrupts, and the cache, and the timers, and the pipelines, and the intricacies of the various CD formats, and the memorycard filesystem, and video modes, and paging, and high impedance, and metastability and everything kind of interacts with everything else so it&amp;#x27;s difficult to maintain a coherent narrative.&lt;p&gt;On top of that a PlayStation is a ridiculously simple system compared to a modern desktop computer. The task of writing a very accessible guide on how to write an OS that would take you from zero to a working userland is absolutely tremendous. I think you could probably write a thousand-page book on the virtual memory subsystem alone.</text></item><item><author>JesseWright</author><text>I&amp;#x27;ve followed Phil&amp;#x27;s site on making an operating system. Ever since having worked on PintOS in college, operating systems and their internals have fascinated me. I&amp;#x27;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&amp;#x27;re already sure of what you&amp;#x27;re doing. Phil&amp;#x27;s articles seems so much more accessible for someone just wanting to dip their toes in the water.</text></item></parent_chain><comment><author>Someone</author><text>&lt;i&gt;”I think writing an OS from scratch is discouraging and not very accessible”&lt;/i&gt;&lt;p&gt;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)&lt;p&gt;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&amp;#x27;t, either, with his first usable system)&lt;p&gt;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.&lt;p&gt;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).&lt;p&gt;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.</text></comment>
<story><title>Writing an OS in Rust: Introduction to Paging</title><url>https://os.phil-opp.com/paging-introduction/</url></story><parent_chain><item><author>simias</author><text>I think it&amp;#x27;s one of these things that&amp;#x27;s more approachable if you start by working on specific subsystems of an existing OS. This way you don&amp;#x27;t have to figure everything out at once. At least that&amp;#x27;s how I did it.&lt;p&gt;I think writing an OS from scratch is discouraging and not very accessible because... writing an OS is discouraging and not very accessible. It&amp;#x27;s a bit as if a painter was saying &amp;quot;It tried looking up guides on how to paint The Wedding Feast at Cana but they all make it look super difficult, I wish I could get an easy step-by-step tutorial&amp;quot;. Even if you break it down in small, digestible parts I&amp;#x27;d wager that you&amp;#x27;ll end up with a few hundred episodes before you even get a basic microkernel up and running on a modern system. It&amp;#x27;s truly a daunting task.&lt;p&gt;I learned that the hard way: I tried to write a guide on how to emulate a PlayStation from scratch. At first you focus on emulating the instructions in the CPU, that&amp;#x27;s relatively focused and straightforward. But then once you&amp;#x27;re done with that you need to explain the various peripherals, and the main bus, and the interrupts, and the cache, and the timers, and the pipelines, and the intricacies of the various CD formats, and the memorycard filesystem, and video modes, and paging, and high impedance, and metastability and everything kind of interacts with everything else so it&amp;#x27;s difficult to maintain a coherent narrative.&lt;p&gt;On top of that a PlayStation is a ridiculously simple system compared to a modern desktop computer. The task of writing a very accessible guide on how to write an OS that would take you from zero to a working userland is absolutely tremendous. I think you could probably write a thousand-page book on the virtual memory subsystem alone.</text></item><item><author>JesseWright</author><text>I&amp;#x27;ve followed Phil&amp;#x27;s site on making an operating system. Ever since having worked on PintOS in college, operating systems and their internals have fascinated me. I&amp;#x27;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&amp;#x27;re already sure of what you&amp;#x27;re doing. Phil&amp;#x27;s articles seems so much more accessible for someone just wanting to dip their toes in the water.</text></item></parent_chain><comment><author>JesseWright</author><text>I fully agree, but I think it&amp;#x27;s good to have options on how to approach the issue. Generally, I&amp;#x27;ve referred to OSDev when I need more real-world information on how things tend to work in practice and resources like Phil&amp;#x27;s when writing a toy operating system.&lt;p&gt;I wouldn&amp;#x27;t consider Phil&amp;#x27;s blog a good resource for, e.g., gaining particular insight into how something like the Linux kernel works, but I also don&amp;#x27;t think Phil intended it for that use.</text></comment>