What type of kernel do you guys plan to design?

[Warrior]

I plan to have a Microkernel in which most of the drivers are in user mode thus having a huge security advantage over the monolithic design.

Say something like a GUI Driver crashes, you can restart the service and anything linked to it and resume what you were doing withought crashing the kernel, and since there is less kernel mode code there is less things probable to cause a fatal error.

The disadvantage of a microkernel is that it needs to context switch (usermode->kernelmode vice versa) frequently which can have a significant decrease in speed but I think that the security advantage is too good to pass up.

Ideas, thoughts?

[Joe]

I'll probably be doing a monolithic kernel, as I don't plan to do much more than string recongnition and doing responces to it (a console). However, if I ever wanted to write a OS which could run third-party programs, I'd go microkernel.

[zorm]

Sure a microkernel isn't going to be more coding and a larger size? I'll likely do a mix but mostly going towards monolithic. Im not sure a microkernel has any real advantages at the end of the day. If you want to upgrade a driver without a reboot you still have to disable/shut off everything thats accessing the device or you might run into lots of problems. Since you have to shut off your programs its causing downtime and well you might as well have just rebooted.

The ekokernel and nanokernel concept is way out there. It may look good on paper but I think if its ever tried it will be found to be not practical.

[Warrior]

Microkernel really has most of the features a monolithic does but it also needs to communicate via message passing which isn't too much code, plus most of the code a monolithic runs in kernel mode a micro runs in user mode making the kernel code smaller but in the end the code is about the same. The effort put into a micro kernel is greater than that of a monolithic one of course since the kernel needs to act as a "server" to communicate which each process in an easy way. Don't monolithics need to shutdown to upgrade a driver, and if they don't what makes microkernels have to because that sounds like a design issue to me. The only time a service and anything using it should be restarted is on a caught exception that is fatal to the service itself.

[zorm]

Im not saying monolithic kernels don't have to reboot just that there is no advantage of being able to restart a service for something like an upgrade without rebooting. I sorta doubt you'll be able to play counter-strike and upgrade your video card driver at the same time. Counter-strike will have to be turned off, so the advantage really isn't there.

On code size, im comparing the kernel+services of a microkernel to that of a monolithic kernel. A microkernel is going to have more because it has to communicate with the services. The microkernel's services also have to have more to talk to the microkernel. The actually code for getting work done should stay the same for both microkernel and monolithic kernel.

[Warrior]

I don't think the upgrading should affect any process running it, just a fatal error.

[zorm]

I'm pretty sure it will unless someone has come up with a magic plan for handling it. I suppose it could be possible but it would require lots more code to preserve the state of what is happening in the driver and to pass it along to the new one.

[Warrior]

What about temporarily pausing it (skipping it in the multitask list) while the driver is update there shouldn't be *that* much speed decrease

[zorm]

Take a webserver running on a microkernel os and a need to update the ethernet driver. In order for a clean pass along the webserver will need to stop accepting new connections. Finish serving ongoing requests/connections. Then the driver update can take place and the webserver can be restarted. But the site will have appeared to be down since the time when it stopped accepting new connections.

The other option as I mentioned in my last post is to 'preserve' the state of the driver and then update it and restore the state. Of course you run into complex issues if you want to do this.

There might be some other option I haven't considered yet *shrugs*

[Warrior]

Hmm..interesting issue :[

[Nate]

What if you have two drivers, a primary and an auxilary. When you want to update the driver, simply update the auxilary, switch everything off the primary to the auxilary.  Then the next time the system restarts, it updates the primary and switches everything back.  This would take up addtional space and probably eat some speed up, but it would result in a more stable OS, if the new driver resulted in errors it would just move everything back to the primary instead of crashing.  Minimal system down time as you could probably just keep swapping back and forth on each update.

[Joe]

..Then the next time the system restarts..

Bada bing, bada boom. You gotta restart.

[Warrior]

I'll find some useful OS Microkernel design topics and share them as I read them, there should be an easy resolve to this issue.

[Nate]

x86] link=topic=1678.msg15141#msg15141 date=1119308319]

..Then the next time the system restarts..

Bada bing, bada boom. You gotta restart.

Bada bing, bada boom.  I said thats if you restart before the next update.

[Warrior]

If you're updating something say the video driver, I think you can update it while it's in use or do how windows does and temporarily freeze the desktop and update then apply all changes (saving it's state of course) and the same can be done for all drivers.