The forums are also excellent. They are a little bit like the Arch Linux forums: People can be a bit snarky, but pretty much everyone is extremely smart and pretty helpful. Noobs are tolerated if they are willing to put in some effort.
This is making me wonder: Thinking about Dan Luu's research on latency of modern systems (https://danluu.com/input-lag/), what is the minimum latency one could get in a modern system (e.g, USB keyboard, modern display hardware)?
I hate to sound dismissive but I feel like a lot of these projects put too much emphasis on booting and too little on something like say process semantics. I've written bootloaders before and it was some of the most uninspired code I've ever written.
Process management is hard. And that's if you throw out all the important stuff like "I want to run my programs outside the kernel" and "It sure would be nice if programs didn't have to share address space".
I recommend the OSDev wiki for a deeper dive but ultimately, implementing processes involves a lot of different moving pieces that need to work.
The most basic process manager would be cooperative, otherwise you'd have to write drivers for some external driver to regularly drive an interrupt.
Cooperative means the program will either print A or B and then call an interrupt into the kernel. The kernel would save the registers and instruction pointer, restore the one of the other program (which prints the opposite of what the first printed; A or B) and do an interrupt return.
This doesn't scale beyond a few processes that you have written yourself very carefully.
Any more competent process management will need to rely on regular timer interrupts, will have to keep track of processes and how much CPU time they got, have a thread to run if nothing else can run, manage processes when they die and has to be able to switch in and out of ring3 for running the actual process. On top of that it has to be performant and efficient, you have only a few hundred opcodes before the latency of your process management becomes too large.
You know, once a machine is running, you can do everything else that's limited by your own imagination.
I've been trying to figure out how a powerpc machine is being booted so that I can insert my own 'hello world' OS. Sure there is a BIOS equivalent somewhere in there, but how to figure out how and when to talk to it?
Booting x86 might seem like nothing, but booting some old SPARC for instance seems like black magic to me.
I think it's because the boot sequence is always pretty much the same on a given architecture, but process management is where things start to depend less on the hardware and more on the OS design.
I just read one chapter, which I thought was OK. It felt more like a book on how the C programming language translates to operating system concepts, rather than a book about the operating system concepts themselves. For example, the chapter I read discusses malloc() and indicates that it allocates memory from the heap, but it doesn't mention sbrk().
x86 16-bit real mode! It's certainly easy, but only because all the real work (initialising the PCI bus to speak to the video card, USB host drivers for the keyboard) is being done by the BIOS somewhere.
Does anyone know these days if the 16-bit boot environment is still "bare metal", or is it inside an UEFI or ACPI hypervisor of some sort?
If you're on UEFI, the 16bit environment is very likely running inside a UEFI "hypervisor" (ie, it puts the CPU into 16bit mode after setting up the appropriate interrupt handlers and hardware drivers). If you boot Windows or Linux via UEFI and not BIOS methods, then you never leave 64bit mode during boot.
Real BIOS that boots from 16bit is quite a rarity these days.
I've not watched the series, but the full stack (ie. Cpu and gpu design in verilog, hdmi, bootstrapped mutitasking os dev, not your average FullStack marketing-speak) for a platform is done by bitwise: https://m.youtube.com/#/user/pervognsen
EFI will kill your program if it runs too long unless it disables a lot of the drives by exiting the boot environment.
Additionally, a lot of the EFI structures aren't intuitive or straightforward since they cover a lot of functionality, you'd still write a lot of code, probably more than the non-EFI variant.
zaarn|7 years ago
0: https://wiki.osdev.org/Main_Page
meuk|7 years ago
dschuetz|7 years ago
I know what I'm gonna do this winter :P
mcculley|7 years ago
ajross|7 years ago
adamnemecek|7 years ago
zaarn|7 years ago
I recommend the OSDev wiki for a deeper dive but ultimately, implementing processes involves a lot of different moving pieces that need to work.
The most basic process manager would be cooperative, otherwise you'd have to write drivers for some external driver to regularly drive an interrupt.
Cooperative means the program will either print A or B and then call an interrupt into the kernel. The kernel would save the registers and instruction pointer, restore the one of the other program (which prints the opposite of what the first printed; A or B) and do an interrupt return.
This doesn't scale beyond a few processes that you have written yourself very carefully.
Any more competent process management will need to rely on regular timer interrupts, will have to keep track of processes and how much CPU time they got, have a thread to run if nothing else can run, manage processes when they die and has to be able to switch in and out of ring3 for running the actual process. On top of that it has to be performant and efficient, you have only a few hundred opcodes before the latency of your process management becomes too large.
dschuetz|7 years ago
I've been trying to figure out how a powerpc machine is being booted so that I can insert my own 'hello world' OS. Sure there is a BIOS equivalent somewhere in there, but how to figure out how and when to talk to it?
Booting x86 might seem like nothing, but booting some old SPARC for instance seems like black magic to me.
jarfil|7 years ago
unknown|7 years ago
[deleted]
dschuetz|7 years ago
unknown|7 years ago
[deleted]
hazz99|7 years ago
http://pages.cs.wisc.edu/~remzi/OSTEP/
It's fantastically well-written, yet detailed without being overwhelming.
peatfreak|7 years ago
kyberias|7 years ago
pjc50|7 years ago
Does anyone know these days if the 16-bit boot environment is still "bare metal", or is it inside an UEFI or ACPI hypervisor of some sort?
zaarn|7 years ago
Real BIOS that boots from 16bit is quite a rarity these days.
alexis_read|7 years ago
Looks very accessible :)
teddyh|7 years ago
zaarn|7 years ago
EFI will kill your program if it runs too long unless it disables a lot of the drives by exiting the boot environment.
Additionally, a lot of the EFI structures aren't intuitive or straightforward since they cover a lot of functionality, you'd still write a lot of code, probably more than the non-EFI variant.
danmg|7 years ago