Oh leuk, OS wars! [Re: [Nlnog] NIET nog es!]

[Boudewijn Visser]

> 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)
> ;-)
>

Uh, ja. Zeker niet Tanenbaum, als hij erg consequent microkernel is,
en Turing deed niet aan overbodige luxe als OSen.
Sterker, Turings bekendste werk deed niet eens aan hardware ;-)


>> 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.

Hm, voor zo ver ik de verschillen begrepen heb is het cruciale
onderscheid tussen micro en monolitische kernels veel meer
kernel-space vs userland, en is het in meer of mindere mate pre-emtible
zijn van de kernel geen criterium.
[zoek zoek zoek... term micro kernel heeft een hoop betekenissen, maar
Bill Stallings noemt ook kernel vs user, en het naar userland brengen van
dingen als device drivers, vmm, filesystems etc. als de typische microkernel
kenmerken. ]

>
> 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.

Blup ? FreeBSD een microkernel ? Ik heb het idee dat de definitie van
microkernel dan wel heel erg veel is verschoven van het comp.sci ideaal,
en Linus' afkeer.
Is dat geen buzzword compliancy ?

AmigaOS is inderdaad een heel fraai OS, maar speelt qua prestatie een
beetje vals vanwege het ontbreken van allerhande protectie, en het OS
maakt daar ook goed ge/mis bruik van.
Dat maakt een deel van de geclaimde voordelen van de microkernel aanpak
nogal zinloos.

JunOS ken ik dan nauwelijks, maar wordt omschreven als een gestripte
BSD kernel waaronder allerlei processen draaien. Wat dat betreft lijkt
het me evenveel of evenweinig microkernel als FreeBSD.

Darwin (is dat het OS deel van MacOS X, of was het wat anders) ken
ik te weinig, maar is dan misschien de beste kandidaat.

>
> 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.

Dat is 1 van Linus' argumenten (theorie vs praktijk ) ;-)
Tsja, mijn oude C128 is ook een Turing machine (en boot een stuk sneller
dan al z'n opvolgers), maar er zijn toch wel wat redenen waarom ik
sommige Turing machine & programma verkies boven andere  ....

Boudewijn