Xref: utzoo comp.unix.wizards:10809 comp.os.misc:494
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!ig!uwmcsd1!uxc!tank!oddjob!uwvax!umn-d-ub!umn-cs!nic.MR.NET!shamash!raspail!bga
From: bga@raspail.UUCP (Bruce Albrecht)
Newsgroups: comp.unix.wizards,comp.os.misc
Subject: Re: Reducing system calls overhead
Summary: OS in user space
Message-ID: <270@raspail.UUCP>
Date: 31 Aug 88 14:12:27 GMT
References: <21606@ccicpg.UUCP> <1316@ast.cs.vu.nl>
Organization: Control Data Corporation, Arden Hills, MN
Lines: 40

In article <1316@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes:
> In article <21606@ccicpg.UUCP> goshen@ccicpg.UUCP (Shmuel Goshen) writes:
> >I have been looking recently at ways to reduce the system call overhead.
> 
> I would suggest you look closely at MULTICS and OS/2, which uses many ideas
> taken straight from MULTICS.  In these systems, the entire operating system is
> contained within the address space of each user process, with appropriate
> protection mechanisms to keep users from doing naughty things.  

Control Data's NOS/VE system on their Cyber 180's works the same way.  However,
this really only works when the memory scheme is based on heirarchial segments.
I can't speak for OS/2, but for Multics and NOS/VE, the memory is set up so
that each segment has ring attributes associated with it, and the ring 
attributes determine what accesses are allowed.  Most, if not all system data
is stored in segments which have ring attributes making them inaccessable to
the user's normal ring level, and the system calls are in segments that are
accessible to the less protected rings.  When a user calls a system procedure,
the ring mechanism automatically lowers the working ring (if the system
procedure's ring attributes indicate this is necessary), so that the heretofore
system data is now accessible.  If one is using an architecture that is not
segmented (such as the 68000 or NSC 32000), it's pretty hard, if not impossible
to automatically make system data accessible for read or read/write with
just a subroutine call.

Another thing I would like to point out is that containing the entire OS within
the user address space, usually cuts down on the maximum user address space.
On the Cyber 180, this is not a problem, because the user has access to 2047
segments of size 2**31.  If you are working with a 68000, you've only got
a single segment of size 2**24 (2**31 for 68020/68030).  If you have system
data that you think the user should be able to read, but not write, you could
map some system data into the user's address space, as part of the system
calling mechanisms (run time library), and make those calls that don't modify
system data subroutine calls rather than system calls (traps).

It is possible to simulate a heirarchial segmented memory schema on a 
non-segmented processor.  Unfortunately, it requires that you trap any call
to a ring outside of the current ring, so that you can reset all of the
read/write/execute attributes on all of the segments (pages) known to the
user.  This is likely to be a lot more expensive than system calls, though.

Bruce Albrecht ({backbone}!shamash!raspail!bga)