On Thu, 2003-09-18 at 23:08, Boudewijn Visser wrote:
Niet in die mate inderdaad. T's argument is meer dat filesystems, de netwerk stack e.d. er *wel* inhoren
Ik vermoed dat de "T" hier "Torvalds" is en niet "Tanenbaum" (of Turing) ;-)
Maar vooral een afkeer van nodeloze complexiteit en traagheid toevoegen vanwege het theoretische ideaal van een microkernel. (Een aantal dingen die altijd zeker in een monolithische kernel zitten worden heel veel trager en complexer in userspace bij een microkernel)
En andersom. Denk aan het filesystem dat op de disk wacht, of de IP stack die op een ARP reply wacht. In een pure monolithische kernel staat het systeem in principe stil gedurende deze tijd, want de kernel kan niet pre-emptive gescheduled worden. Dus heeft men de Pinguin opgezadeld met Bottom Half handlers, Task Queues, Wait Queues... Feitelijk niets meer dan hacks om ervoor te zorgen dat de kernel de CPU niet nodeloos vasthoudt. Er wordt een soort van scheduler emulatie in de kernel ingebouwd, naast de bestaande process scheduler... die nota bene alleen werkt alleen als alle onderdelen van de kernel zich netjes gedragen (dus ook de dynamic kernel modules). Vergis je niet, dit maakt de kernel een stuk complexer dan strikt noodzakelijk. Bij alle functionaliteit die wordt toegevoegd moet je goed kijken of er plekken zijn waar je de CPU tijdelijk kunt vrijgeven. Dit "nette" pre-emptive gedrag krijg je gratis bij de microkernel opzet -- ten koste van wat overhead, maar ik denk dat er ergens een omslagpunt ligt. Er zijn trouwens genoeg voorbeelden van prima werkende (en presterende) microkernels: AmigaOS, FreeBSD, JunOS, Darwin. T & T hebben allebei een beetje gelijk. Geen van beide aanpakken is 100% heilig. Overigens heb ik colleges bij Tanenbaum gelopen, maar gebruik ik de kernel van Torvalds... en uiteindelijk is alles een Turing machine. Groeten, Steven