Hi,
Brynet-Inc wrote:Craze Frog wrote:When they implemented dynamically loadable modules in the monolithic kernel they call it hybrid.
Who does? Most people call that "Modular Monolithic"... not hybrid..
Agreed. Hybrid is where you have some things running in kernel space and other things running in user space (e.g. disk and network drivers in kernel space, with video drivers in user space).
Craze Frog wrote:asdx wrote:can a full microkernel with ipc server message-passing outperform and be faster than a monolithic kernel in performance/development time?
Of course. A fast microkernel will be faster than a slow monolithic one.
Agreed, but the performance penalty can be significant - for the microkernel to perform better than a monolithic kernel you'd need an extremely well optimized micro-kernel and a very poorly implemented monolithic kernel.
Development time is a completely seperate issue. In my experience, in the early stages a microkernel is slower to develop because you need to spend more time designing (and documenting) the interfaces between seperate pieces. However, in the long term it can be faster to develop an OS with a microkernel because it's easier to debug device drivers - you get feedback from the extra protection and exception handlers, you might be able to use some extra kernel features (like I/O port, IRQ and IPC logging), and you might even be able to use normal debugging tools (like GDB). Depending on your specific situation there's possibly other benefits, like being able to run 32-bit device driver binaries on a 64-bit kernel (without rewriting or recompiling them as 64-bit code), being able to start and stop device drivers to test them without rebooting, etc.
IMHO, while performance and development time are important, they aren't the most important issue. The most important issue is trust: do you trust an anonymous "binary blob" of code from companies like NVidea, Sony, etc (and/or any random hacker that's pretending to be NVidea, Sony, etc) enough to give the binary blob full access to everything? If you don't trust anonymous binary blobs, what are you going to do about them?
A good microkernel uses
the principle of least privilege to minimize the amount of damage an anonymous binary blob can do, so that the binary blob doesn't need to be trusted much.
A monolithic OS must trust the anonymous binary blobs. For open source monolithic OSs they tend to avoid binary blobs as much as possible because of the risks (or because of the lack of protection) - they try to force people into using open source instead. This is probably not a good idea because some companies have a lot of cash invested in their own intellectual property and are reluctant to make open source drivers, and some companies licence intellectual property from others and don't have a choice. In the end you could waste a massive amount of time reverse engineering something that a company would have been happy to provide as closed source (or under NDA, or under licence).
Note: In addition to the technical reasons, there are also ideological and economic reasons for the "everything must be open source" mentality that I'd rather avoid.
For a closed source monolithic OS you're mostly screwed and need to rely on "brute force" methods - validation testing, digitally signed device drivers, anti-virus software, etc. IMHO none of these methods will work well for an OS with a small market share.
Cheers,
Brendan