From owner-freebsd-hackers  Wed Mar 27 12:52:33 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA25985
          for hackers-outgoing; Wed, 27 Mar 1996 12:52:33 -0800 (PST)
Received: from seagull.rtd.com (root@seagull.rtd.com [198.102.68.2])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA25960
          for <freebsd-hackers@freefall.FreeBSD.org>; Wed, 27 Mar 1996 12:52:25 -0800 (PST)
Received: (from dgy@localhost) by seagull.rtd.com (8.6.12/1.2) id NAA19259; Wed, 27 Mar 1996 13:52:14 -0700
From: Don Yuniskis <dgy@rtd.com>
Message-Id: <199603272052.NAA19259@seagull.rtd.com>
Subject: Re: OSF Micro Kernel for Linux/FreeBSD/etc
To: terry@lambert.org (Terry Lambert)
Date: Wed, 27 Mar 1996 13:52:14 -0700 (MST)
Cc: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers)
In-Reply-To: <199603271823.LAA01607@phaeton.artisoft.com> from "Terry Lambert" at Mar 27, 96 11:23:40 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

It seems that Terry Lambert said:
> 
> >      OSF/1 MK is a serverized version of OSF/1, the same as Mach
> > 3.0/UX is the serverized version of Mach 2.x.  Basically they took the
> > code that was above the Mach layer and moved it into a server, just
> > keeping the Mach abstractions in the kernel.  However, lately even
> > OSF/1 MK has been doing ``In Kernel Servers'', where they move the
> > server back into the kernel's address space and sort-circuit the RPC's
> > (turn them into function calls) to get better performance.
> 
> Message overhead is the reason that Chorus changed tactics (Chorus is

I assume that was especially nasty for their COOL runtime.

> a "competing" microkernel that USL was using to implement the next
> version of System V after SVR4.2 was released; it ran "NetWare" and
> "UnixWare" personalities simultaneously).  The amount of protection
> domain crossing in MACH is prohibitive for anything but monolithic
> servers... the performance just isn't there otherwise.

The real win (actually !lose) is when the RPC's are truly remote as in
a NoW application.