Milrokernel ist mehr, als mur Treiber im Userspace. Und der Kommunikationsoverhead zwischen den Kerneldiensten, die aus dem Mikrokernel ausgelagert sind, fuehrt sicher nicht zu einer besseren Performance.
> Ein Microkernel wäre eine Lösung. Treiber laufen dann im Userspace und man hat keine Probleme mehr.
Und das löst das Problem der Abstraktionschichten und wachsender Codegrösse wie? Du hast halt einen Haufen User daemons laufen, statt eines Kernelprozesses, so what?
Linux ist bereits wesentlich mehr `micro' als früher und wird mehr und mehr `micro' werden, so weit das zu einem beliebigen künftigen Zeitpunkt technisch sinnvoll ist. Der Hype um jene Kernelkonzepte die im akademischen Sinn als `echt micro' gelten ist bzw. war in erster Linie ... ein Hype.
Dass Linux heute als Kernel (für GNU und andere) benutzt werden kann ist unter anderem dem Umstand zu verdanken, dass es früher nicht `micro' genug war um für Akademiker als schick durchzugehen. Zum Glück. MINIX war `echt micro' und MINIX war unbrauchbar für die `real world' (genauso wie HURD, nebenbei gesagt), der Entstehungsgrund für Linux. Um dessen `microness' würde ich mir nicht unbedingt große Sorgen machen - die ist absolut auf der Höhe der Zeit und wandelt sich weiter, mit der Zeit.
Was die Geschwindigkeitseinbußen angeht, zeigt die Nachricht meiner Meinung nach vor allem eines, nämlich dass das Frühwarnsystem der Community erwartungsgemäß funktioniert. In der proprietären Welt gibt es diverse Software-Hersteller die Jahre lang hinter verschlossenen Türen an einer neuen Betriebsystemversion herumentwickeln um den Anwender pünktlich zum Release mit der ernüchternden Tatsache vertraut zu machen, dass die Performance im Vergleich zum Vorgänger unterirdisch ist
was Minix angehst, so tust Du dem ganzen Unrecht. Es sollte gar nicht wirklich gut einsetzbar sein, sondern vor allem leicht zu verändern. Der Prof. Tannenbaum hatte es zu speziell dem Zweck entwickelt und Patches mit Verbesserungen, die es aber komplexer machen, regelmäßig abgelehnt.
Dass Linux ihm als zu fett gilt, liegt nicht an den vielen Treibern. Die sind ja nur Module und werden bei Bedarf nachgeladen, sonst nicht. Das klappt ganz gut. Was es fett macht, sind eher die 4 Arten von RAID, die sich darin verewigt haben, und jeweils andere APIs und anderen Code haben. Oder fnotify, inotify und wie auch immer die Vereinigung jetzt heisst. Oder /proc, /sys und debugfs, oder jetzt auch devfs2, etc.
Es gibt Unmengen an Interfaces, die kaum mehr jemand braucht, die Last erzeugen, weil Implementierungen sie bedienen können müssen, und Code fressen. Ich hoffe dass Linus versuchen will, auf ein Linux 3.0 zu kommen, dass inkompatibel ist, und alles unnötige an Altlasten wegwirft.
Von Jo:rg Zweier am Di, 22. September 2009 um 21:58 #
++
Dem kann ich mich nur anschließen. So langsam müssen die Kernelentwickler wirklich dazu übergehen, ihre APIs zu "standardisieren", sodass es auch die Anwendungsentwickler leichter haben und sich auf die wesentlichen Dinge konzentrieren können.
Ein Microkernel wäre eine Lösung. Treiber laufen dann im Userspace und man hat keine Probleme mehr.
> Ein Microkernel wäre eine Lösung. Treiber laufen dann im Userspace und man hat keine Probleme mehr.
Und das löst das Problem der Abstraktionschichten und wachsender Codegrösse wie? Du hast halt einen Haufen User daemons laufen, statt eines Kernelprozesses, so what?
Dass Linux heute als Kernel (für GNU und andere) benutzt werden kann ist unter anderem dem Umstand zu verdanken, dass es früher nicht `micro' genug war um für Akademiker als schick durchzugehen. Zum Glück. MINIX war `echt micro' und MINIX war unbrauchbar für die `real world' (genauso wie HURD, nebenbei gesagt), der Entstehungsgrund für Linux. Um dessen `microness' würde ich mir nicht unbedingt große Sorgen machen - die ist absolut auf der Höhe der Zeit und wandelt sich weiter, mit der Zeit.
Was die Geschwindigkeitseinbußen angeht, zeigt die Nachricht meiner Meinung nach vor allem eines, nämlich dass das Frühwarnsystem der Community erwartungsgemäß funktioniert. In der proprietären Welt gibt es diverse Software-Hersteller die Jahre lang hinter verschlossenen Türen an einer neuen Betriebsystemversion herumentwickeln um den Anwender pünktlich zum Release mit der ernüchternden Tatsache vertraut zu machen, dass die Performance im Vergleich zum Vorgänger unterirdisch ist
was Minix angehst, so tust Du dem ganzen Unrecht. Es sollte gar nicht wirklich gut einsetzbar sein, sondern vor allem leicht zu verändern. Der Prof. Tannenbaum hatte es zu speziell dem Zweck entwickelt und Patches mit Verbesserungen, die es aber komplexer machen, regelmäßig abgelehnt.
Dass Linux ihm als zu fett gilt, liegt nicht an den vielen Treibern. Die sind ja nur Module und werden bei Bedarf nachgeladen, sonst nicht. Das klappt ganz gut. Was es fett macht, sind eher die 4 Arten von RAID, die sich darin verewigt haben, und jeweils andere APIs und anderen Code haben. Oder fnotify, inotify und wie auch immer die Vereinigung jetzt heisst. Oder /proc, /sys und debugfs, oder jetzt auch devfs2, etc.
Es gibt Unmengen an Interfaces, die kaum mehr jemand braucht, die Last erzeugen, weil Implementierungen sie bedienen können müssen, und Code fressen. Ich hoffe dass Linus versuchen will, auf ein Linux 3.0 zu kommen, dass inkompatibel ist, und alles unnötige an Altlasten wegwirft.
Gruss,
Kay
Dem kann ich mich nur anschließen. So langsam müssen die Kernelentwickler wirklich dazu übergehen, ihre APIs zu "standardisieren", sodass es auch die Anwendungsentwickler leichter haben und sich auf die wesentlichen Dinge konzentrieren können.