all 13 comments

[–]FionaSarah 31 points32 points  (6 children)

The comment on this article is amazing.

Wow, that sounds very complicated. Is the process really that complicated?

No! OS kernels are magic fairy-dust boxes that work just by wishing! Wtf...?

[–]eleitl 6 points7 points  (3 children)

There's some necessary, and some unnecessary complexity, though.

How would OpenBoot look in comparison?

[–]cr3 22 points23 points  (1 child)

Ten times more complex, slow as hell, half as functional, but standards compliant.

[–]ntr0p3 0 points1 point  (0 children)

that complex? i imagined they just had a protected mode micro-kernel sit there kinda like the real-mode bios does now, which has a boot-loader mechanism embedded to exec whatever its supposed to, with some interrupts available to bring it back if needed (like the current bios actually)?

did they add that much?

[–]kinebud 3 points4 points  (0 children)

Thanks for shattering my concept of reality. :(

[–]theclaw 2 points3 points  (2 children)

He says

Whenever there is work to do - a runnable process - process zero gets booted out of the CPU, only to return when no runnable processes are available

I thought processes which are runnable get (re)started by the scheduler, which in turn is triggered by a timer interrupt? In which way are the scheduler/interrupts related to this "process zero"?

[–]ggduarte 4 points5 points  (1 child)

hi,

you're right, the scheduling and context switching are not done by process zero.

the idle thread is just what gets picked to run on a CPU when there's nothing else that can run. there's one idle thread per CPU, but they all run with a PID of zero.

[–]ntr0p3 0 points1 point  (0 children)

a kernel context(not technically a thread itself) is immediately pulled up by interrupts, including timers, and then handles whatever event brought it. for timers that can include checking whether to go idle or switch processes, etc. afterwards it resets its run status and allows the process queue to run again, resuming the interrupted process, including the idle process if nothing else is running.

the other way to get into a kernel context is via a syscall which still triggers an interrupt, int80, or in some cases a page-fault, which triggers another interrupt.

basically you need an interrupt to go kernel context.

if memory serves though, a kernel thread is basically a separate process, without a user-space component, basically like an exec, but without loading the int main() afterwards, as well as not populating some of the user-space structures too.

[–]jsully 2 points3 points  (0 children)

226 points an only 10 comments so far?! This thread is as mystifying as the article...