help

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
gtk

help

Post by gtk »

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
carbonBased

RE:help

Post by carbonBased »

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
Post Reply