From owner-freebsd-hackers Tue Apr 22 10:04:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA25046 for hackers-outgoing; Tue, 22 Apr 1997 10:04:54 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA25041 for ; Tue, 22 Apr 1997 10:04:49 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA26548; Tue, 22 Apr 1997 10:02:12 -0700 From: Terry Lambert Message-Id: <199704221702.KAA26548@phaeton.artisoft.com> Subject: Re: Price of FreeBSD (was On Holy Wars...) To: james@westongold.com (James Mansion) Date: Tue, 22 Apr 1997 10:02:12 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: <335C7EB6.7E62@westongold.com> from "James Mansion" at Apr 22, 97 10:02:46 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > Microkernel systems can be as efficient as monolithic ones. Modularity > > > > > > Name one. The very requirement of the boundaries will introduce a cost > > > that you could avoid with a direct function call. > > > > Chorus; it does not enforce protection domains between OS servers and > > the OS, only between the OS & OS servers and user space. > > So? Are you saying that the executing thread calls directly between the > servers, like (say) a call to an in-proc COM server? Yes. Without the idiotic "free thread marshaller" imposed by the misdesign of the virtual memory system in NT/95. [ ... direct call and/or vtable instruction fixup call ... ] > or: [ ... indirect call through marshalling interface ... ] > Perhaps simplified somewhat. I'll grant you that if the monolithic > kernel has to hand over control to kernel internal threads then you > get it all back, but that's essentially a case of a Chorus-like MK > design with the server running internally. You don't need to do the marshalling if you are in the same VM space; the NT/95 "free threading" model is actually broken in this regard because of a design issue in the VM/"Viper" framework interaction. It's not something they are going to be able to change easily because it touches on historical handling of process address spaces for non-threaded processes. They might have been able to do it if they required free-threaded COM modules to have specific section coloring for the shared data regions, and the virtual construction had to take place into a seperate heap region with the same (shared) attributes. But now they are doomed to an eternity of free-thread marshalling because of their treatment of object instantiation vis-a-vis thread local storage. Pity, that. > Clearly if you allow a thread to carry its execution directly into a > server and to hop between them then you remove the overhead, but my > understanding of the terminology is that one expects and MK 'server' > to be an executing entity rather than a DLL. "Server" or "Service"? Even in the MS case, a not-in-process server running on the local machine does not have to have free thread marchalling for "Apartment" or "Rental" model threading... and then that's exactly what the threads are doing: moving into the other code. The "Free Threading" case is a mistaken process address space implementation on MS's part; your heap is your heap. Chorus doesn't really follow the MACH "server" model terribly closely (that's why it's fast). The point of having a "server" rather than a "service" is to provide an execution context in the seperate protection domain on which the request may be serviced... no protection domain, no seperate execution context. I don't know what happened to them after I left Novell, but there was some success reported in porting UnixWare and NetWare to run on a common Chorus kernel and set of services. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.