4 ms·

The use of the term microkernel has stronger connotations than just having a bigger part of the system in userland. The intent was to have the minimum possible

The use of the term microkernel has stronger connotations than just having a bigger part of the system in userland. The intent was to have the minimum possible functionality in the kernel. At the extreme this meant just resource allocation and messaging between processes. I would say that it then becomes a matter of opinion how much more one can add to the kernel before it stops being a microkernel. The advantage of a microkernel is that it should be able to be made more robust and secure than its more monolithic cousins as the code that is, in principle, capable of taking out the whole system is small and slow moving. On that basis, saying that Linux is not considered a microkernel is a fairly safe statement. Where I believe general purpose microkernels have struggled is in the performance of the messaging (often because of the increased access checking). More targeted uses have been successful. Probably the standout one being QNX which has been used extensively in the embedded space.

digi_owl 10y ago
I think QNX is more famous as a real time kernel than a microkernel.
- Animats 10y ago
  QNX is a microkernel done right. For three years I used it as a desktop OS while doing real time development. Firebird (a predecessor of Firefox) and Thunderbird ran, so I had browsing and mail. Running QNX on a desktop is a smooth experience. There's no paging, so there are no paging delays. It has real-time responsiveness, so there are none of those brief stalls you get with Unix and Linux. QNX's problem is the ownership. The business has been sold twice (to Harmon, an audio company, and to RIM/Blackberry). The code has gone from closed source to free version available to closed source to open source to closed source with no free version. Third party developers were so fed up they stopped developing for it. Now QNX no longer supports itself as self-hosted; you have to cross-compile from Windows. The problem with the Hurd is that they tried to take a big OS, Mach or BSD, and make a microkernel out of it. Mach itself started with BSD and tried to make a microkernel out of it. Wrong approach. You have to start from nothing and build a minimal microkernel. All QNX has in the kernel is CPU dispatching, memory management, timers, and message passing. Everything else is in user space. To get things started, the boot image can contain user programs which are loaded during boot and then started. That's how the initial drivers and file systems get loaded. For many embedded applications, that's all that gets loaded - there may not be a file system. For bigger systems, the initial drivers are just enough to allow loading more stuff from disk. It's annoying that nobody else, with the possible exception of the L4 people, seem to be able to get this right. The QNX kernel is only about 60K bytes of code.
- jacquesm 10y ago
  QNX is famous as a real time kernel because it is a microkernel. 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.
  - viraptor 10y ago
    What do you think it's holding us back from?
    - jacquesm 10y ago
      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.
  - wolfgke 10y ago
    > 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).
wolfgke 10y ago
> Where I believe general purpose microkernels have struggled is in the performance of the messaging (often because of the increased access checking). Jochen Liedtke's work on the L4 kernel family showed that microkernels can be really fast.
xj9 10y ago
You should look at the L4Linux papers[1]. [1]: http://l4linux.org/papers.shtml http://l4linux.org/papers.shtml

digi_owl 10y ago

I think QNX is more famous as a real time kernel than a microkernel.

Animats 10y ago
QNX is a microkernel done right. For three years I used it as a desktop OS while doing real time development. Firebird (a predecessor of Firefox) and Thunderbird ran, so I had browsing and mail. Running QNX on a desktop is a smooth experience. There's no paging, so there are no paging delays. It has real-time responsiveness, so there are none of those brief stalls you get with Unix and Linux. QNX's problem is the ownership. The business has been sold twice (to Harmon, an audio company, and to RIM/Blackberry). The code has gone from closed source to free version available to closed source to open source to closed source with no free version. Third party developers were so fed up they stopped developing for it. Now QNX no longer supports itself as self-hosted; you have to cross-compile from Windows. The problem with the Hurd is that they tried to take a big OS, Mach or BSD, and make a microkernel out of it. Mach itself started with BSD and tried to make a microkernel out of it. Wrong approach. You have to start from nothing and build a minimal microkernel. All QNX has in the kernel is CPU dispatching, memory management, timers, and message passing. Everything else is in user space. To get things started, the boot image can contain user programs which are loaded during boot and then started. That's how the initial drivers and file systems get loaded. For many embedded applications, that's all that gets loaded - there may not be a file system. For bigger systems, the initial drivers are just enough to allow loading more stuff from disk. It's annoying that nobody else, with the possible exception of the L4 people, seem to be able to get this right. The QNX kernel is only about 60K bytes of code.
jacquesm 10y ago
QNX is famous as a real time kernel because it is a microkernel. 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.
- viraptor 10y ago
  What do you think it's holding us back from?
  - jacquesm 10y ago
    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.
- wolfgke 10y ago
  > 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).

wolfgke 10y ago

> Where I believe general purpose microkernels have struggled is in the performance of the messaging (often because of the increased access checking). Jochen Liedtke's work on the L4 kernel family showed that microkernels can be really fast.

xj9 10y ago

You should look at the L4Linux papers[1]. [1]: http://l4linux.org/papers.shtml http://l4linux.org/papers.shtml