Re: Verständnisfrage über Linux-Kernel
* Tobias Nissen <tn@movb.de> schrieb:
moin,
> Ich bin mir ziemlich sicher, dass das mit einem Micro-Kernel, bei dem
> die einzelnen Subsysteme hübsch Message-Passing betreiben, nicht
> passiert wäre. Verteilte Programmierung mittels Message-Passing ist
> nunmal einfach weniger Fehleranfällig und leichter zu Debuggen und
> _viel_ einfacher zu programmieren.
Das Hauptargument für monolitische Kernel ist ja meist die
Performance - message passing verbraucht halt immer ein klein wenig
mehr Zeit als ein direkter call. Andererseits erldigen sich damit
aber auch eine Menge Locking-Probleme von selbst, der Code wird
schmaler und leichter wartbar. Im HA-Bereich spart man sich mitunter
auch allerhand lästige Reboot's.
Für mich persönlich ist aber die Frage micro- vs. monolith.
Kernel nicht so entscheidend - eher die gesamte Systemstruktur drumrum.
Wenn man sich zB. anschaut, mit wie wenigen syscall's Plan9 auskommt
und dennoch bzw. gerade deshalb ein so mächtiges und auch sehr leicht
ausbaubares System ist, dann könnte sich die GNU/Linux-Gemeinde
davon schon die eine oder andere Scheibe abschneiden.
Im Grunde genommen brauchen wir keinen neuen Kernel, sondern sollten
eher für jedes Subsystem oder Feature die Frage stellen, ob sich
das wirklich im Kernel befinden muß.
Beispiel Filesysteme:
Es gibt eine Menge FS'e, die praktisch nie zum Booten gebraucht werden
(oder nur in Spezialfällen, wo man getrost initrd nehmen kann) und
auch nicht so unheimlich Performance-kritisch sind, zB. smbfs, nfs,
coda, etc. Die könnte man sehr leicht auch via 9P2000 andocken und
spart ich damit auch gleich allerlei Schleifen zurück ins Userland
(uid-mapping, cache-daemon, ...)
Beispiel USB-Gerätetreiber:
Für die meisten USB-Devices braucht man eigentlich keinen Kerneltreiber,
das könnte alles im Userland laufen - der Treiber-Prozess holt sich
via device-node oder sysfs Zugriff auf die USB-channels und erledigt
seine Arbeit im Userland. Wenn's *wirklich* nötig ist (zB. bei NICs),
kann man dann den Output über die etablierten Interfaces wieder
zurück in den Kernel schieben.
Beispiel Netfilter-Config:
Die gesamte Netfilter-Configuration könnte man auch bequem über text-
orientierte Filesystem-Interfaces lösen. Damit fallen auch die ganzen
Probleme mit binären netlink-Interfaces weg (32/64-bit-Probs, etc.)
Der ganze Code wäre viel schlanker, und als Frontend reichen sogar
ein paar Shellscripts.
usw. usw. usw
Ich hab diese Dinge schon länger auf der Agenda, aber allein kommt
man da schlecht voran :( ... Falls sich jemand berufen fühlt,
hier mitzumachen, einfach mal Bescheid geben :)
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
Reply to: