The reasoning behind the bad idea
Although the value of OS projects has been discussed for decades and it is completely true that it is impossible for a single human being to be able to beat what has been built in the span of almost half a century by sheer willpower alone, many fail to identify that it is as much of a waste of time as it is playing videogames, partying or painting (to list a few examples). While a person should aspire to become the best version of themselves and of course aim to be productive in their day-to-day life, they should also not deprive themselves of the comfort that is having activities that aren’t aimed at making the best out of the limited time they have on Earth. If people only worked towards goals that granted them success in areas like money, it would be unhealthy and much harder to maintain than doing the same things but with hobbies aside. If you want to spend your free time doing something, as long as you don’t harm others or yourself, you should do it.
Being so close to finishing what’s only the beginning of my education in computers, I am starting to understand just how limited my knowledge is, and instead of being okay with it, I am hungry for more. I don’t understand a lot of things, and I don’t like the feeling of not understanding something while at the same time I love the feeling of doing it. One of the things that I have found incredibly interesting is how we can bridge the gap between the machine and the final user. In class, we’re told multiple times that an OS is, essentially, “the software that lets the user control the hardware”, but then we just move on. Sure, we might receive a few lessons on the boot process, memory management and the difference between physical memory and paging, but it’s not enough for me. Given that I want to understand as much as I can and the fact that the time spent would be taken from playing video games and doomscrolling, I have decided to be the one that closes that gap while understanding as much as I can in the process. I might fail, or rather, I know I will absolutely fail, but there’s no one holding me at gunpoint to succeed and there’s no one paying me based on my performance in this field, so I, with due respect, don’t give a fuck about making mistakes.
The choices
The context
When looking at a project as big as this one, it is really important to know what you’re going to deal with beforehand. I don’t know as much as I’d like as I’m writing this, but I have already done a few attempts and I’ve started to see what I actually want to achieve. My first attempt was last summer around this time, when I wrote a bootloader and a kernel targeting the x86_64 architecture. But saying “I” would be incorrect, because at that time I was underprepared and relied heavily on AI to help with both assembly and C. That changed the project from learning how to make a computer boot and how to handle keyboard input to learning how to use AI efficiently to get things done, and I hated it. I didn’t understand 90% of what was going on, and I eventually stopped the “development”. However, I didn’t leave empty-handed because I learned what a bootloader was, why assembly was needed, why C was arguably the best programming language for OS development and what the interrupt table was. It was a lost battle, but a step towards winning the war. This year (I don’t remember when) I tried again, this time using OSDev as a source of information and AI as an explanation source only. This way, I got to use the bare-bones basic kernel that the wiki provides for x86 32 bits to add newline character support and terminal scrolling. I understood how to use VGA to display text and change colors and I felt ready to go ahead and go for interrupts again. This was possible because I actually took the time to learn C at a basic level using a YouTube video that covered the fundamentals, which made reading the basic code mentioned earlier much easier (or rather possible, as I didn’t understand it last year at all). But again, I couldn’t do interrupts because I didn’t understand them deep enough. I know what they are used for and how they work in concept, but not “in code”, and my little kernel kept crashing with triple fault. As I made the mistake again of relying more on AI than in documentation, I ended up frustrated because my goal was never to finish a product, but to understand one.
The fresh start
As I was looking to restart this project this summer, I remembered that x86 isn’t the only architecture out there, and I started to investigate different architectures. There were 3 main options: x86, ARM and RISC-V. x86 wasn’t out of the picture because the idea of having a pendrive I can plug into almost any computer and boot my own OS to show it to peers was super cool, but I’d choose to go for UEFI and 64 bits instead of BIOS and 32 bits. ARM was quickly out of the picture as I read it’s proprietary and it’d be harder to develop for it. RISC-V, however, seemed amazing. It’s got fewer instructions, it doesn’t carry 30 to 40 years of retrocompatibility and it’s open for anyone to tinker. There are also mini computers that would allow me to take that step if I ever wanted to while still having support for virtualization in the early stages. It also has its own firmware called OpenSBI, which would make my code work for any RISC-V chip that has said firmware. Because of all that, I chose RISC-V to be my platform.