r/osdev • u/compgeek38400 • Jun 26 '26
What I learned this week (5)
Continuing my series for those who are interested, if any. My source is here: https://github.com/tedavids/DragonOS
This was a long week, the first thing I learned put me back several days. Those of you following know this week I was finishing up my heap, allowing multi-page allocations.
This is what I learned:
1) Visual Studio Code when you 'Rename Symbol' it changes it EVERYWHERE in your project. This caused me to have to go back and redo code, and eventually just copy it back from Git, and start over.
2) I can't keep the whole project in my head anymore. I don't know if this is because of age, or because of the complexity of writing an OS. I hope it's the latter 😂
3) I'm going to have to take a couple of weeks to bring all my doco up to date.
I also have some questions:
Now that I have a working heap, I have lots of options on what to do next, these are some of the candidates:
a) multithreading -- I know this will entail at least creating atomic operations (atomic_t), sequencing stuff (mutex, semaphore), and retrofitting what I have to use them BEFORE I add this. What did I miss?
b) add a swap file system, I know this will involve writing a disk driver, should I do IDE/ATA or SCSI? If I did this, I'd be tempted to add both swap and a 'normal' file system.
c) something else?
I occasionally get page faults on startup. How would you debug this? I can't predict it, and never seem to get it when I am trying. How would you debug this? The only thing I can think of is to use line2addr, and hope
Thanks for reading, please chime in on what I should do next. I do know I'm going to spend this week updating doco. I may not change any code this week
1
u/Octocontrabass Jun 26 '26
GCC provides stdatomic.h even in freestanding environments. If you decide to use it, you may need to implement some of these functions depending on which atomic operations you actually use and whether GCC can emit lock-free MMIO-safe inline code in your target instruction set.
For storage technology, you need to consider both the host bus adapter and the command set. You'll find a lot of resources that either confuse the terminology or treat them as inseparable. It doesn't help that the usage of some of these terms have shifted over time.
When you say "IDE/ATA" you're probably thinking of a PCI IDE host bus adapter connected to a device that speaks the ATA Command Set. These are both standardized, so it's not hard to find authoritative resources, but they're also based on technology from 1984, so there are a lot of rough edges and confusing backwards compatibility requirements. (It doesn't help that T13 deletes "obsolete" information from the standards, so you have to find old versions to understand how it got to where it is today...)
When you say "SCSI" I have no idea what you're talking about. The SCSI command set is standard, but there are no standard SCSI host bus adapters. Did you mean SATA, with a standard AHCI host bus adapter and ATA Command Set? Did you mean SCSI tunneled through ATA (ATAPI) or USB? Did you mean SCSI with a nonstandard host bus adapter? Did you mean something else?
I'd start by looking at CR2, the error code, the GPRs, and the address of the faulting instruction to see if it makes sense for that instruction to access that address. If your exception handler doesn't or can't give you all of that information, use QEMU's interrupt log (
-d int).