@All: Klar, daß bei einem monolithischen Kernel der overhead zum dynamischen Nachladen der einzelnen Module entfällt; Bei einer geschickten Implementation dieser Dynamik fallt das aber nur unwesentlich ins Gewicht.

Was mir aber als wesentlicher Vorteil einer Microkernel-Architektur erscheint, ist die Tatsache, daß sich einzelne Module leichter austauschen lassen. U.U. brauche ich dann für ein Kernel-Update nur mehr einige Module neu kompilieren und installieren, und das update ist fertig - ohne Neustart. Das funktioniert aber nur dann, wenn klar definierte SChnittstellen zwischen den Modulen gibt, die sich nicht alle paar Versionen ändern; Das resultiert dann in Inkompatibilitäten zwischen Modulen und Kernel, und genau das ist ein Problem das m.A. Linux z. Zt hat. Dadurch daß Module immer an einen bestimmten Kernel gebunden sind, ist es für kommerzielle Anbieter sehr schwierig, Treiber für Linux zu entwickeln, wenn sie diese nicht gerade als Open Source freigeben möchten.

Ich möcht hier nicht wieder eine Neuauflage des Flame-Krieges OOS vs Closed Source anzetteln, aber es würde sicher einiges bei den Open Source OSes besser gehen, wenn es ein einheitliches Treiber(Modul)modell gäbe.

War da nicht einmal ein Ansatz in diese Richtung?