osdev: overhaul
Prelude
This is my first blog on osdev, my journey of operating system development.
I started osdev on the winter holiday of 2023, which has been 4 months.
Indeed, as warned by The Hard
Truth, osdev is a
time-consuming and hard project.
In the past 4 months, I have carried this project as a nighttime hobby.
I managed to set up a basic framework by using Meaty
Skeleton and enabled GDT and IDT by
following many useful resources. I’m currently working on
paging.
Two important things that I experienced (I was going to say learned, but I
still feel unsure about whether I have learned the gist) so far:
- Working with uncertainties.
- It’s amazing how uncertain osdev is. There are fewer resources, less nice carry-you-all-the-way YouTube videos, and fewer boot camp courses. Osdev trained me to read the documentation (the Intel manual), dig into ancient 2000s forums, and read other projects’ code (in this case, xv6 served me well). There are less “best practices,” at least less than I can search for. Every decision is a choice, that may or may not lead me to a brighter path. Honestly, I haven’t even set a scope or goal for this project, but I’m starting to enjoy this uncharted ocean.
- How to get things moving.
- This is related to the uncertainties. Because I could take too many paths, I kept spending time deciding one and less on actually writing code. After a while, I realized that it is way more important to get my hands dirty and start to write something. The answer won’t just pop up when I’m sitting and thinking. Write something, anything, even some trashy spaghetti, that can serve as a base that I can work on top of. Overthinking is useless.
Overhaul
Overhaul is a series that tries to flatten the project structure of Meaty Skeleton (will reference as MS).
Motivation
I liked
AS, because of its nice separation between userspace and kernel and the
consideration of hardware compatibility and future extendability.
However, I
loathed it because of the nesting directories and overall complex organization
brought by its well-rounded design. I’m not saying its design is bad, but it is
stirring my brain. I have to keep spending energy understanding the project
structure and its implications.
I believe MS will serve its value when the project is more mature, but I need to
focus on writing code right now instead of walking that directory maze.
So, I decided to flatten the whole directory, a bit like how xv6 does
it. I reaffirmed my decision after
reading Should your source code be in one folder or should it be
nested,
and Favour flat code file
folders.
Action
Well, this is simple. Let’s move all the regular files to the project’s root directory. It’s done! And, not surprisingly, boom! Okay, the build system is not happy
because I just flipped its world upside down.
To make the build system happy again, I need to read
the Makefile and trace how it was doing things; then, I need to adjust all
the Makefile variables, build path, shell scripts, etc., to satisfy my current
flattened view. I’ll save the details from being listed here simply
because it is tedious and complex.
Onward
One result of having a flat directory is that the kernel code is no longer
separate from the libc, or libk(ernel) in this case. I can’t see an urgent need
to separate them apart; it could be that I’m very inexperienced, but I’ll leave it
this way until there is a need to extract out libk.
After finishing overhaul, I learned a lot about Makefile and the whole MS build system, and I can see this knowledge immediately in use
continuing down my osdev journey. Once again, this series is not a denial of the
value of directories and a more structured codebase but a makeshift change that
helps me get through this turbulent starting phase by eliminating the overhead of
maintaining the MS structure. I can finally focus on
writing the code now.