Unfortunately this book has the classic fault of osdev tutorials: lots of talking about x86 minutiae, very little osdev. X86 minutiae is not osdev. It is a vanishingly small portion of what even a basic OS has to deal with.
It would be great if there were more hobby OS resources targetting something other than X86. It is common and everything, but all the bootstrapping and device cruft involved isn't something you should need to get in your head, and 386 assembly by itself is terribly frustrating and obtuse to write by hand. I think most people might be better off starting out with a RISC microcontroller. There isn't nearly as much bullshit involved between getting a running kernel and talking some simple serial, and you can get an instruction set reference, assembler manual, and processor datasheet that will tell you everything you need to know. And it's easy to have fun hardware hacking that way too, making your own peripherals and such.
I think working with a ready-made Unix isn't as friendly to the idea of 'hobbying' an OS. For studying how Unix works, it's great. But if I wanted to make experimenting with my own bespoke system worth it, I would try to not have preconceived notions about how it should work, or copy an entire design. There are dime-a-dozen Unix-workalike hobby OSes out there, and in the shoes of an experimentalist there's a lot to weigh you down in the Unix ecosystem, and a lot of things worth trying that break from the way Unix does things.
If you really did want to work with an existing OS for actual research/experimentation purposes, and you're a fan of C, I would go with Plan 9/9front. There's a reason Bell Labs ditched Unix--because it wasn't a worthy research platform anymore.
>The old xv6 is x86-based and it's not officially maintained anymore.
Which is sensible. There's way too much legacy crap and ugliness that needs to be dealt with in that ISA to distract from the purpose of the project, which is to teach OS development.
- Get multitasking working in x86 since there are a ton of guides for that. Learn OSdev concepts.
- Read the ARMARM. It's many thousands of pages of dense technical material, nearly everything you need to get started. The only parts it doesn't cover are boot media/formats and peripherals.
There aren't good resources for ARM osdev because the environment is not standardized at all. ARM chips are used everywhere and you're often targeting specific boards, not chips. Writing the ARM-specific stuff is only half the battle.
True. I'm guessing it's the same reason that lexing and parsing are the focus of many langdev guides, despite being amongst the smallest/simplest parts of the compiler. I guess it makes sense, since those topics are the entry point into the field and at some point your learning is mostly self-directed.
People talk in hushed and revenant tones of SICP despite it having little to do with modern computing architecture. Perhaps x86 is still a great way to cut one's teeth.
The issue is not that x86 is mentioned. It's just that there is a lot more to an operating system than just getting code running on a CPU.
RPC, the input stack, the graphics stack, the network stack, audio, profiling, telemetry, scheduling, UI toolkits, security, service management, application management, etc.
If you want to learn these things you will need to read the documentation and source code for other OSs.
X86 also has little to do with modern computing architecture. That's just the ISA; it's not going to help you solve pipelining or cache issues inherent to the data flow.
Wishing x86 on students is sincerely such a sadistic act. Just pick an arbitrary isa that's easier to reason about (read: basically anything after 1990 not designed by intel) and stick to it.
x86 machines are cheap and ubiquitous. It is astoundingly easy to google for help/tips or ask random people on the net.
There are also really good virtual machines and emulators available.
Most of the weirdness came in in the 286 and can be more or less ignored. The parts that can't be ignored happen mostly during initialization.
If you want to baby step your way towards assembler and hw programming, DOSBox + an IDE/debugger setup from the late 80's/early 90's is really not a bad combo. That could be Turbo/Borland Pascal or C(++) with Turbo Debugger and Turbo Assembler, for example. You get a running environment, you have direct access to the hardware (DOS won't stop you), you can access it from Pascal/C, you can use inline assembler in both, and you can use external assembly files if you want. You can even successfully single-step and use breakpoints a lot of the time.
A Raspberry Pi or similar is a good alternative. I don't think any non-ARM platform is.
I don't find the x86 minutiae objectionable. If you want to build or even just understand an OS that runs on real hardware, you will have to deal with processor and hardware minutiae, and this gives one example of what you might encounter and how to deal with it.
For most OSes the amount of code that actually deals in processor minutiae is really quite small. Portable logic makes up the majority. Maybe an exception can be drawn for some very particular OSes like DOS or Windows 9x.
So you read a tutorial and it spends about 90% of its time talking about an area that really isn't that interesting compared to other areas. I just don't think that's very compelling at all.
I say this having my own hobby OS which I've ported to four architectures (m68k, amd64, aarch64, riscv). At the moment I'm working on a TCP/IP stack which has been really enjoyable and I've learnt a great deal in doing this already. Other fun areas have been virtual memory and page replacement, designing asychronous I/O facilities, and IPC mechanisms, as well as appropriate synchronisation for each (synchronisation alone is a very deep topic, and there's considerable scope for innovation with techniques like safe memory reclamation.) Others may differ, but in these I find a lot more of interest than x86 minutiae.
Without knowing much about the type of OS this book is, I imagine that there a lot of architectural aspects of x86 are considered "standard" to many of the x86 OSes out there. I hear a lot about code density in the x86, MIPS, and SH-2, compared to a lightweight RISC processor. Or, the book glazes over some of the more universal aspects of OSes, to address specific features of x86.
https://github.com/rswier/swieros is a cool project that uses it's own VM (with a C compiler included). I was surprised by all the capabilities it has.