For further reading, I can't recommend enough this free book:
http://pages.cs.wisc.edu/~remzi/OSTEP/
It's fantastically well-written, yet detailed without being overwhelming.
Let’s write a Kernel with keyboard and screen support (2014)
11–20 of 40 posts
Re: Let’s write a Kernel with keyboard and screen support (2014)
#12I 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.
Less is more, right? Also, there are two kinds of bootloaders: simple + reliable, and bloated + buggy.
grub is pretty bloated but also reliable.
Finding the kernel is not as easy as it used to be. You need to read the partition table on the disk. You need to be able to understand the filesystem that the kernel is stored on. This adds a fair bit of complexity.
Re: Let’s write a Kernel with keyboard and screen support (2014)
#13x86 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?
Re: Let’s write a Kernel with keyboard and screen support (2014)
#14Build a custom/weird CPU: https://cpudev.org/wiki/Main_Page
and write an OS for it: https://wiki.osdev.org/Main_Page
I know what I'm gonna do this winter :P
Re: Let’s write a Kernel with keyboard and screen support (2014)
#15Earlier quoted context omitted.
Less is more, right? Also, there are two kinds of bootloaders: simple + reliable, and bloated + buggy.
grub is pretty bloated but also reliable. Finding the kernel is not as easy as it used to be. You need to read the partition table on the disk. You need to be able to understand the filesystem that the kernel is stored on. This adds a fair bit of complexity.
On a modern UEFI system you actually get provided with an API that can do all that for you, though only FAT32 partitions are supported for the FS out of the box (you can load your own drivers for more).
If your boot partition is FAT32, UEFI makes things much much simpler.
Re: Let’s write a Kernel with keyboard and screen support (2014)
#16I 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.
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.
Re: Let’s write a Kernel with keyboard and screen support (2014)
#17Earlier quoted context omitted.
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'…
If anyone wants to try this, on x86 getting a regular interrupt for preemptive multitasking is pretty easy, you can write an interrupt handler for the [real-time clock]( https://wiki.osdev.org/RTC ). This will work on any PC and takes about 15 lines of code to set up. Every 1ms, whatever's running will be paused and your scheduling code can run. Actually writing the scheduler is the hard part ;)
I second that. My degree project was a 68K-based RTOS kernel with a simple preemptive task scheduler, and the scheduler was one of the easiest and smallest parts of the whole project.
Re: Let’s write a Kernel with keyboard and screen support (2014)
#18I may be wrong, but if you assume a non-ancient x86 platform with EFI BIOS, don’t you get all this for free from drivers included in EFI?
Re: Let’s write a Kernel with keyboard and screen support (2014)
#19x86 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.
Re: Let’s write a Kernel with keyboard and screen support (2014)
#20Earlier quoted context omitted.
If anyone wants to try this, on x86 getting a regular interrupt for preemptive multitasking is pretty easy, you can write an interrupt handler for the [real-time clock]( https://wiki.osdev.org/RTC ). This will work on any PC and takes about 15 lines of code to set up. Every 1ms, whatever's running will be paused and your scheduling code can run. Actually writing the scheduler is the hard part ;)
I second that. My degree project was a 68K-based RTOS kernel with a simple preemptive task scheduler, and the scheduler was one of the easiest and smallest parts of the whole project.
Realtime Schedulers have it a bit more easy IMO than non-realtime.
For RT you can write a scheduler that at any point knows if all processes will meet their deadlines and you can easily design an algorithm to get to the most efficient scheduling order.
In non-RT it gets harder because a process might not need to run at all and is just eternally paused on reading some dead socket, it might have higher priority than other processes, you might have 2000 processes to run but only 1000 timeslots left for the current timeslice.
A process might begin to eat up CPU time and you have to somehow preserve the interactivity of the system, ie prevent other processes from starving without starving the big process in turn.
And once you enter multi-CPU it gets even harder; coordinating multiple concurrent schedulers to run from the same task queue, which cannot ever take a simple spinlock without the system suddenly becoming dead.
The parent comment simply noted that setting up the timer interrupt is fairly easy (though if you want something precise and faster than 1ms and multicore it might get more complicated), it's the stuff after that were you are forced to solve NP-hard problems in a fast way.