summaryrefslogtreecommitdiff
path: root/microkernel
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@schwinge.name>2009-11-22 18:48:39 +0100
committerThomas Schwinge <thomas@schwinge.name>2009-11-22 18:48:39 +0100
commitcfd490a382d928d07ed98e0104ac5b7ebf9d38e5 (patch)
tree9b44928c100b25ca04889a2e6af7f7753dfa1214 /microkernel
parentfcb280ce60424ef1e19f1840267458fa680cd257 (diff)
Typo fix. Found by Emilio Pozuelo Monfort.
Diffstat (limited to 'microkernel')
-rw-r--r--microkernel/fud.mdwn2
1 files changed, 1 insertions, 1 deletions
diff --git a/microkernel/fud.mdwn b/microkernel/fud.mdwn
index eef829e0..6353f81d 100644
--- a/microkernel/fud.mdwn
+++ b/microkernel/fud.mdwn
@@ -17,6 +17,6 @@ But L4 takes this even further. For example, you can have schedulers in userspac
Of course, microkernels still have some problems, mainly because we are bound to today's technology, and current processors have not been designed with microkernels in mind. On a processor that is not optimized for systems with monolithic kernels, where the currently still problematic overhead of context switches would vanish, microkernels would get another performance boost. This sounds like an excuse, but it is intended as a reminder about the fact that the problem is not the general concept of microkernels. However, the L4 people have done a lot of good hacks to work around all this and have reached reasonable performance already.
-All this could be discussed in arbitrary detail, but we won't do that now, as we have more urgent things to do than reacting on FUD about microkernels. So we will conclude by saying that it is too easy to claim that one design is fast and the other one is slow, but everything depends on how exactly a system is designed and implemented. Maybe microkernels will eventually turn out to be slower in almost any case; we doubt that, but who knows? But even then, a microkernel based system will offer enough other advantages so that people will prefer to use it in some cases. But on the other hand, history has shown that new concepts seldom replace old ones completely, but rather establish themselfes in addition to the old ones, therefore we will have the opportunity to argue about which concept is best at least for another couple of years.. or decades?
+All this could be discussed in arbitrary detail, but we won't do that now, as we have more urgent things to do than reacting on FUD about microkernels. So we will conclude by saying that it is too easy to claim that one design is fast and the other one is slow, but everything depends on how exactly a system is designed and implemented. Maybe microkernels will eventually turn out to be slower in almost any case; we doubt that, but who knows? But even then, a microkernel based system will offer enough other advantages so that people will prefer to use it in some cases. But on the other hand, history has shown that new concepts seldom replace old ones completely, but rather establish themselves in addition to the old ones, therefore we will have the opportunity to argue about which concept is best at least for another couple of years.. or decades?
If you are interested in research about the performance of microkernel based systems, visit <http://www.l4ka.org> and <http://os.inf.tu-dresden.de/L4/>