Thanks for sharing. Been meaning to read this for some time now. It’s part of 2020 MIT course on Operating Systems.
I’ll use this thread to lay out parts of an idea maze I’ve been investigating lately.
What’s the least amount of code it takes to build an OS? If you care a lot about performance you end up needing a device driver for every new piece of hardware on the market, and so the amount of code is fairly unbounded. So let’s resign ourselves to some lower level of performance.
Starting from the other end, a hobbyist 8- or 16-bit OS is easy to build and many people have done so, including fantasy consoles like the PICO-8. Real hardware is also not too difficult to support, thanks to the BIOS (which I’ve been thinking of as the instruction set for everything but the processor).
If you need 32-bit to access more than 64KB RAM and you’re willing you run emulated, projects like xv6 exist.
xv6 also works on real hardware and not just Qemu: https://hoblovski.github.io/2019/03/16/Running-xv6-on-my-laptop-with-grub.html
You can use VESA BIOS Extensions (VBE) for the screen, and for reasonable resolutions all modern hardware will be supported.
You can use PS/2 for keyboard and mouse, and again modern hardware will work.
The network is more tricky. There have been class projects to give xv6 a network stack that works on qemu: https://github.com/vibhorvatsa/xv6-networking-stack
However, I’m not aware of a working network stack for xv6 on real hardware.
It’s also not clear to me if there’s a good lowest-common-denominator standard for the network that all ethernet cards support. It’s on my todo list to investigate something called the “em” network driver.
Beyond ethernet lies wifi. I know nothing of it yet.
Even further beyond lies the boss level of pressure-sensitive multi-touch devices. There I have zero conception of even what interface a device driver should expose.
Corrections and suggestions most appreciated!