OSDev.org

I am a CS student developing my own operating system and interested in ultra-secure/ultra-stable systems. The question i am researching right now is "What is the optimal kernal size?". Personally, i prefer a minimal kernel with add-in modules. However, i have heard arguments for larger kernels somwhere along the lines that "if you eliminate the module boundaries, you don't have to do a context-switch to execute functions as often". While this is certainly a valid argument, given that a well-written context switch algorithm can take 1000 clocks or less, are we willing to give up 1 microsecond for the added encapsulation (and therefore security) of modularity?


Thanks for your responses,
gtk

Yes

There any may ways to speed of task switching, etc, and that "microsecond" keeps getting smaller.

Not to mention, by using shared memory it _might_ be possible to get away without even swtiching... hmm... bare with me... this random thought just popped into my head...

Every task has the same "stub" function-call-loader mapped somewhere into memory... probably about the 3gb mark.  The module id is placed in eax (for eg).  From there, the stub decides which page map to load into CR3, and does so (this page map also includes the stub, so that it can continue executing after the CR3 load).  After CR3 is loaded, the correct module is now mapped into address space, and the stub jumps to it... it executes, and returns the value back to the stub, which switches back to the applications address space, and returns the result.

Hmm....

Yes, well... interesting theory, but... it wont work lol.  Upon further thought, it's pretty apparent that a task switch is needed... the stub would have to run in ring 3, which can't set CR3

Oh well... it was a thought

Cheers,
Jeff