Live data from Hacker News

Let’s write a Kernel with keyboard and screen support (2014)

arjunsreedharan.org

1–10 of 40 posts

Re: Let’s write a Kernel with keyboard and screen support (2014)

#3
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.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#6

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.

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.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#7

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.

Less is more, right? Also, there are two kinds of bootloaders: simple + reliable, and bloated + buggy.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#8

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.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#10
post #8

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'…

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 ;)
Post reply on HN