5 ms·

Now micro kernel doesn't seem that stupid after all?

by zouhair 17y ago

snprbob86 17y ago
Despite the snarky tone of your comment, you hint at an interesting point: Unix is NOT the be-all, end-all definitive operating system. Linux is NOT even the be-all, end-all Unix (or Unix-like). There is A LOT of research left to be done in operating systems / kernels and many many years of evolution to come. It's a shame that it is SO HARD to build the ecosystem required to launch a kernel. New ideas are hard pressed to gain traction.
- pyre 17y ago
  You realize that OS X uses a micro-kernel, right? And that GNU Hurd is a micro-kernel too?
  - m0th87 17y ago
    I wouldn't say OS X is a microkernel. Much of its codebase was built off of Mach, but much was also built off of BSD. For example, its network stack logic resides in the kernel, which is certainly not microkernel-esque. See http://en.wikipedia.org/wiki/Darwin_(operating_system)#Kernel http://en.wikipedia.org/wiki/Darwin_(operating_system)#Kerne...
  - vinutheraj 17y ago
    "Mac OS X is sort of microkernelish. Inside, it consists of Berkeley UNIX riding on top of a modified version of the Mach microkernel. Since all of it runs in kernel mode (to get that little extra bit of performance) it is not a true microkernel, but Carnegie Mellon University had Berkeley UNIX running on Mach in user space years ago, so it probably could be done again, albeit with a small amount of performance loss, as with L4Linux. Work is underway to port the Apple BSD code (Darwin) to L4 to make it a true microkernel system." - Andy Tanenbaum reference - http://www.cs.vu.nl/~ast/reliable-os/ http://www.cs.vu.nl/~ast/reliable-os/
    - pyre 17y ago
      I realize that. On the same note, GNU HURD isn't technically a 'micro-kernel' because GNU Mach is the micro-kernel, but my point was that 'micro-kernel' instead of 'monolithic kernal' isn't some unexplored territory that only exists as theory in CompSci textbooks.
  - snprbob86 17y ago
    I'm not talking about just micro- vs macro- kernel. I'm talking about general OS-level research. Just look at what MSR is doing with Singularity: http://research.microsoft.com/en-us/projects/singularity/ http://research.microsoft.com/en-us/projects/singularity/
  - yardie 17y ago
    OS X is not a microkernel and hasn't been one since 10.0. It is a hybrid kernel called the XNU kernel. It's Mach microkernel based with some low layer BSD smothered on top. It would be interesting to see how the original Mach microkernel runs on modern hardware. At the time, the context switching of the Mach kernel was making performance poor. But this was on 300/400 MHz machines.
- tomjen2 17y ago
  Is it really so hard to gain traction? Just write a UNIX micro kernel and add a compatibility layer for Linux device drivers, then you are set.
  - Tuna-Fish 17y ago
    Define "linux device driver". Doing what you ask could easily require including most of linux.
  - scythe 17y ago
    Isn't that what l4linux does? ( http://l4linux.org/ http://l4linux.org/ )
  - eru 17y ago
    The exo-kernel guys tried to go a route that radically eases evolution. Normally an operating system tries to abstract and protect/multiplex. They were writing a sort of microkernel, that only multiplexes/protects users from each other, but exported the raw hardware interface to userland. The abstracting part of the OS would be implemented as (possibly shared) shared libraries.
    - steveklabnik 17y ago
      I'm actually (well, my friends are doing most of the work now) still writing one: http://www.xomb.org/ http://www.xomb.org/
      - eru 17y ago
        Interesting. I visited the wiki and will have a deeper look into it later.
        steveklabnik 17y ago
        Let me know if you have any questions, or feel free to jump on #xomb on freenode. We usually have a few people idling.
- likpok 17y ago
  Launching a kernel is easy. Making people want to use it is hard, as most apps people want are boring to write and/or trapped in the poor design decisions of the past (e.g. POSIX).
CitizenKane 17y ago
A micro kernel doesn't necessarily mean that there will be less bloat. It just means that different parts of the functionality of the kernel are split up into different programs. But those programs have to talk to each other, and this message passing overhead increases with increased functionality (more programs). So it seems likely that there would be a definite performance drop as the functionality of a micro kernel increased.
yason 17y ago
How would it reduce the bloat mentioned in the article? Would there be somehow less code to implement the same features in a microkernel architecture?
- m0th87 17y ago
  Mot less code to implement, but it modularizes logic such that it's (theoretically) trivial to disable unneeded features. I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit. There are a lot of other side benefits. As stable as Linux is, it still has a great deal of code executing in kernel mode, which is error-prone; microkernels can restart crashed processes on-the-fly without compromising the stability of the system rather easily. Also, some of the newer microkernels have formal proofs of their security properties, which is pretty damn fascinating! (albeit they assume the underlying proof system itself is error-free, which might not be true)
  - deleted 17y ago
    [deleted]
  - Tuna-Fish 17y ago
    As anyone who has ever run Kconfig knows, linux is already very well modularized, and disabling unneeded logic at compile time is already easy, and most of the kernel actually resides in dynloaded modules these days. > I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit. Such code doesn't matter. Most of it is in a dynloaded module, so it doesn't even eat ram, and even the stuff baked in the kernel hardly matters for performance -- the < 5 megabytes of ram doesn't even hurt in cellphones anymore, and the thing that hurts most is L1i cache use, where only code that is actually executed goes. The bloat we are talking about is not the increase in the total size of the kernel, but the increase of the size of the commonly executed code paths. Linux being a microkernel would not help there, in fact it would hurt.
    - fauigerzigerk 17y ago

Now micro kernel doesn't seem that stupid after all?

by zouhair 17y ago

Now micro kernel doesn't seem that stupid after all?

Despite the snarky tone of your comment, you hint at an interesting point: Unix is NOT the be-all, end-all definitive operating system. Linux is NOT even the be-all, end-all Unix (or Unix-like). There is A LOT of research left to be done in operating systems / kernels and many many years of evolution to come. It's a shame that it is SO HARD to build the ecosystem required to launch a kernel. New ideas are hard pressed to gain traction.

pyre 17y ago
You realize that OS X uses a micro-kernel, right? And that GNU Hurd is a micro-kernel too?
- m0th87 17y ago
  I wouldn't say OS X is a microkernel. Much of its codebase was built off of Mach, but much was also built off of BSD. For example, its network stack logic resides in the kernel, which is certainly not microkernel-esque. See http://en.wikipedia.org/wiki/Darwin_(operating_system)#Kernel http://en.wikipedia.org/wiki/Darwin_(operating_system)#Kerne...
- vinutheraj 17y ago
  "Mac OS X is sort of microkernelish. Inside, it consists of Berkeley UNIX riding on top of a modified version of the Mach microkernel. Since all of it runs in kernel mode (to get that little extra bit of performance) it is not a true microkernel, but Carnegie Mellon University had Berkeley UNIX running on Mach in user space years ago, so it probably could be done again, albeit with a small amount of performance loss, as with L4Linux. Work is underway to port the Apple BSD code (Darwin) to L4 to make it a true microkernel system." - Andy Tanenbaum reference - http://www.cs.vu.nl/~ast/reliable-os/ http://www.cs.vu.nl/~ast/reliable-os/
  - pyre 17y ago
    I realize that. On the same note, GNU HURD isn't technically a 'micro-kernel' because GNU Mach is the micro-kernel, but my point was that 'micro-kernel' instead of 'monolithic kernal' isn't some unexplored territory that only exists as theory in CompSci textbooks.
- snprbob86 17y ago
  I'm not talking about just micro- vs macro- kernel. I'm talking about general OS-level research. Just look at what MSR is doing with Singularity: http://research.microsoft.com/en-us/projects/singularity/ http://research.microsoft.com/en-us/projects/singularity/
- yardie 17y ago
  OS X is not a microkernel and hasn't been one since 10.0. It is a hybrid kernel called the XNU kernel. It's Mach microkernel based with some low layer BSD smothered on top. It would be interesting to see how the original Mach microkernel runs on modern hardware. At the time, the context switching of the Mach kernel was making performance poor. But this was on 300/400 MHz machines.
tomjen2 17y ago
Is it really so hard to gain traction? Just write a UNIX micro kernel and add a compatibility layer for Linux device drivers, then you are set.
- Tuna-Fish 17y ago
  Define "linux device driver". Doing what you ask could easily require including most of linux.
- scythe 17y ago
  Isn't that what l4linux does? ( http://l4linux.org/ http://l4linux.org/ )
- eru 17y ago
  The exo-kernel guys tried to go a route that radically eases evolution. Normally an operating system tries to abstract and protect/multiplex. They were writing a sort of microkernel, that only multiplexes/protects users from each other, but exported the raw hardware interface to userland. The abstracting part of the OS would be implemented as (possibly shared) shared libraries.
  - steveklabnik 17y ago
    I'm actually (well, my friends are doing most of the work now) still writing one: http://www.xomb.org/ http://www.xomb.org/
    - eru 17y ago
      Interesting. I visited the wiki and will have a deeper look into it later.
      - steveklabnik 17y ago
        Let me know if you have any questions, or feel free to jump on #xomb on freenode. We usually have a few people idling.
likpok 17y ago
Launching a kernel is easy. Making people want to use it is hard, as most apps people want are boring to write and/or trapped in the poor design decisions of the past (e.g. POSIX).

CitizenKane 17y ago

A micro kernel doesn't necessarily mean that there will be less bloat. It just means that different parts of the functionality of the kernel are split up into different programs. But those programs have to talk to each other, and this message passing overhead increases with increased functionality (more programs). So it seems likely that there would be a definite performance drop as the functionality of a micro kernel increased.

yason 17y ago

How would it reduce the bloat mentioned in the article? Would there be somehow less code to implement the same features in a microkernel architecture?

m0th87 17y ago
Mot less code to implement, but it modularizes logic such that it's (theoretically) trivial to disable unneeded features. I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit. There are a lot of other side benefits. As stable as Linux is, it still has a great deal of code executing in kernel mode, which is error-prone; microkernels can restart crashed processes on-the-fly without compromising the stability of the system rather easily. Also, some of the newer microkernels have formal proofs of their security properties, which is pretty damn fascinating! (albeit they assume the underlying proof system itself is error-free, which might not be true)
- deleted 17y ago
  [deleted]
- Tuna-Fish 17y ago
  As anyone who has ever run Kconfig knows, linux is already very well modularized, and disabling unneeded logic at compile time is already easy, and most of the kernel actually resides in dynloaded modules these days. > I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit. Such code doesn't matter. Most of it is in a dynloaded module, so it doesn't even eat ram, and even the stuff baked in the kernel hardly matters for performance -- the < 5 megabytes of ram doesn't even hurt in cellphones anymore, and the thing that hurts most is L1i cache use, where only code that is actually executed goes. The bloat we are talking about is not the increase in the total size of the kernel, but the increase of the size of the commonly executed code paths. Linux being a microkernel would not help there, in fact it would hurt.
  - fauigerzigerk 17y ago