Date: Wed, 27 Mar 1996 03:20:23 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: sclawson@bottles.cs.utah.edu (steve clawson) Cc: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers) Subject: Re: OSF Micro Kernel for Linux/FreeBSD/etc Message-ID: <199603271020.DAA09781@seagull.rtd.com> In-Reply-To: <199603270840.BAA11882@bottles.cs.utah.edu> from "steve clawson" at Mar 27, 96 01:40:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > And yet someone else said: Yeah, *me*! ;-) > > > Um, speaking *mostly* from ignorance but I think Mklinux is implemented > > > as a single-server atop Mach. So, in that sense, it's still a monolithic > > > kernel (albeit residing atop a microkernel). I don't think they've really > > > gone too far afield and tried for a multi-server... Can someone shed any > > > more light on this? > > It's basically what's been called a ``single server''. This has > been a pretty standard implementation technique for servers on Mach. > Basically you take a monolithic system, hack off the bottom and > replace that with calls to Mach. Since you have to worry about Yes. This was the case with bsdss, UX and poe. But, US actually tries to be a multiserver... but a bit of a resource hog :-( > preemtability in user space, generally there's a certain amount of > locking/threading that also takes place, although none of the single > servers that I know about are terribliy multithreaded (generally > there's a ``unix master lock'' that you have to aquire before doing > much of anything). Not to mention the problems in implementing the emulation library in a "robust" form -- especially if a shared object! > There have been a couple attemts at a multi-server on Mach, > Mach-US and the Hurd being the two best known examples. > > > I have talked with peoples from DEC Moscow about DigitalUnix (former OSF/1). > > They said that the last version of it has monolithic kernel on top of Mach. > > They said also that DEC did this for both performance and stability reasons. Performance is a big issue in a microkernel implementation. And, a multi-server implementation has oodles of traps waiting to screw the unwary implementer! > > So it looks like the microkernel is a bad idea yet. Although, I know that > > peoples in DEC Moscow indeed have very little information from DEC about > > anything except prices :-) and their words may be completely wrong. > > OSF/1 has always been a monolithic system. It's based on Mach > 2.x, which is basically just 4.3BSD code that was modified to make I thought 2.5? > Mach low-level calls instead. There is no server, since everything is > in the kernel. Even if there was a server, I wouldn't venture to call > anything Mach `micro'. =) > > 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. "That's the rub", unfortunately :-( Though I thought your migration code was trying to address some of this -- at least for the local case (?) --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603271020.DAA09781>