Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!usc!sdd.hp.com!spool2.mu.edu!uunet!mcsun!unido!ira.uka.de!fauern!opal!tmpmbx!scuzzy!src
From: src@scuzzy.in-berlin.de (Heiko Blume)
Newsgroups: comp.unix.sysv386
Subject: Re: binary Mach distribution for 386
Message-ID: <1991Jan10.163048.20613@scuzzy.in-berlin.de>
Date: 10 Jan 91 16:30:48 GMT
References: <13963@uswat.UUCP> <1991Jan4.140341.11874@granite.cr.bull.com> <1991Jan05.021138.17495@scuzzy.in-berlin.de> <1991Jan5.180851.24
Organization: Contributed Software
Lines: 26

shore@mtxinu.COM (Melinda Shore) writes:
>In article <1991Jan07.152536.28530@scuzzy.in-berlin.de> I wrote:
>>i always considered
>>this [the micro-kernel] one of the main advantages.

>I don't.  The idea is nice, but it's generally pretty slow to run on
>top of a micro-kernel (Chorus is an exception).  You pay in the form
>of more context switching and more data movement.  A lot of the
>performance problems have been worked out of 3.0, but there's still
>some work to be done.  The *real* advantage of Mach is the abstractions
>that it provides the programmer.  

well, it's certainly much slower if you always have to relink that
damn huge monolithic kernel and reboot if you changed something in the
serial driver :-)

i think all those intelligent peripherals, like scsi host adapters, multiport
and ethernet cards, with their own processors and RAM can help a lot with
these performance problems. Given the possibilty to write and test drivers 
without relinking the kernel etc., i expect/hope to see quite nice mach 3.0
machines pretty soon.
-- 
      Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93
                    public source archive [HST V.42bis]:
        scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
                     uucp scuzzy!/src/README /your/home