>
Many real world interactions require hard real time and with monolithic kernels you are just not going to be able to meet your guarantees.
Lots of hard realtime systems (e.g. on microcontrollers) use a RTOS where there is even no distinction between user and system mode, thus one cannot even talk about microkernels vs. monolithic. From a software engineering architectural perspective this is not a good design, but it is very fast (thus the time guarantees you can give are smaller) and sometimes easier to guarantee runtime guarantees. And it is easier to write a RTOS where all things run in system mode (which does not imply it is easier to debug bugs or to maintain).
Re:Whatever happened to the Hurd? (2012)
by jacquesm on Saturday August 27, 2016 @03:36AM
(#12371441)
It is much easier to develop drivers and system processes for a micro kernel because they run in isolation, you can hot re-load any one of them and if it is designed properly you can even upgrade the kernel on a running system without a reboot.
What do you think it's holding us back from?
Re:Whatever happened to the Hurd? (2012)
by jacquesm on Saturday August 27, 2016 @03:33AM
(#12371428)
A much higher level of responsiveness from applications and operating systems. This is hard to quantify but if you've used a system like QNX as your desktop machine the continuous irritation at small 'freezes' of your machine would evaporate, you could control hardware directly from user processes without dedicated CPUs to drive time-critical stuff and so on.
Hard real time seems like a luxury until you've worked with it in practice and then you wonder why it isn't a basic requirement of any half decent operating system.
All the scheduling power of QNX derives directly from having all non-essential code in user processes rather than in the kernel, which does only one thing and does that very well (message passing).
I've re-implemented a 32 bit version of QNX long ago, maybe one day I'll attempt to move it to the 64 bit era if I can figure out a way to automatically convert linux device driver source code to an 'administrator' (QNX parlance for a daemon). That should take the sting out of re-writing each and every driver under the sun.
I strongly believe that Linux not being micro kernel based (and not in a 'minix' sense but a real micro kernel with all services as user processes) is one thing that is currently holding us back.
Many real world interactions require hard real time and with monolithic kernels you are just not going to be able to meet your guarantees.