Levels of UNIX, an opinion, a question

[Guy Harris]

> In the paging-in-somewhere discussion someone asked if UNIX has any levels
> besides kernel and user.  I believe not; it originated on a PDP-11, probably
> one without supervisor level (I'm not sure).

UNIX only uses "kernel" and "user" mode (to use DEC terminology; on a M68000,
they would be "supervisor" and "user", on a 360/370/43xx/308x/..., they
would be "supervisor" and "problem", etc.)  The original original UNIX ran
on a PDP-7 with no modes, the next one ran on a PDP-11/20 with no modes,
and the next one ran on a PDP-11/45 with "kernel", "supervisor", and "user"
modes.  However, I guess nobody saw a use for "supervisor" mode on a PDP-11.
DEC certainly didn't; none of their OSes at the time even used separate I&D
space!  Later, MERT used "supervisor" mode to provide an extra layer, and
both UNIX and RSX-11M+ (which had just discovered separate I&D space) used
"supervisor" mode to increase the kernel and user address spaces, respectively.

Later, when DEC came out with the VAX-11, they had learned several things:

1) you need more than two modes to run an operating system :-)
2) you don't need a reference bit to implement paging :-)

So they dumped the I/O library into "executive" mode and the command
interpreter into "supervisor" mode in VMS.  I guess that was so nobody could
corrupt the system by using other than the DEC-approved I/O libraries and
command language :-(.

> The shell was outside the kernel because of the address space limit.

The shell was outside the kernel because nobody could think of a good
reason for putting it in the kernel, but they could think of several good
reasons for *not* putting it there:

	1) It means you can change it without a note from the system
	   administrator
	2) It means it doesn't need special privileges, and
	3) It forces the operating system to grant *all* privileges
	   useful to command interpreters to *all* programs, such as
	   the ability to create new processes, execute programs,
	   redirect I/O, etc.

> The question: where should one draw the line on putting shell, terminal
> features, editor, etc when the machine has a huge address space?

     Ideally, a system shouldn't have *any* modes; it shouldn't draw
rigid uncrossable lines between some kinds of services and others, and
should rely on good programming discipline to keep everybody and their
brother from inventing slightly-different versions of various system
services and using them.

     In practice, this has trouble on multi-user systems and can even
be a problem on single-user systems, because implementing some system
services requires the implementing code to have privileges that would
enable the implementing code to accidentally or deliberately destroy
system data or other processes.  (There *are* big systems which have
no notion of privileged vs. unprivileged mode; the Xerox "Mesa Processors"
and their Pilot operating system - the Xerox Star is a "Dandelion" Mesa
Processor running Pilot and the Star application programs - have no such
notion.)

     And, once a privileged/unprivileged mode barrier is constructed,
it can sometimes be expensive to cross this barrier; the overhead for
a "system call" is often quite a bit higher than that for a regular
procedure call, and data often must be copied between "kernel" (privileged)
and "user" (unprivileged) address spaces.

     So, once "kernel" and "user" modes become necessary, things get put
into the kernel for three reasons:

	1) They require the privileges of kernel mode;
	2) They don't require those privileges, but they must use
	   kernel facilities so frequently and are not used as
	   frequently by higher-level facilities that the system would
	   be more efficient if they were in kernel mode;
	3) Other.

     "Other" covers a multitude of sins.  Sometimes, it just means "somebody
thought it should go there.  However, on systems such as (most implementations
of) UNIX, the only way to have a facility's code be shared by and available
to all programs without linking it into all programs (which creates several
copies of the code, increasing the memory requirements for that code) is to
put it into the kernel.  Or the facility may manage a shared resource, and
if the system doesn't support shared data segments and mutual exclusion
at the level of user-mode code (as standard UNIX systems didn't until
recently), the only way for the facility to have shared data and mutual
exclusion is to put it into the kernel.

     The arguments for screen paging in the kernel fall under class 3),
with the latter two reasons being the ones usually cited.  There are other
ways of achieving those goals; implementing paging with a filter gives you
the second goal (code sharing) by putting it into a process with shared
text (rather than putting it into a library) and give you the third goal
by giving the filter the exclusive use of the terminal (anybody doing output
to the terminal is doing it through that filter, at least in principle).
(I shall make no claim as to which side is right here, mainly because I
haven't decided myself.  I can live with it in the kernel or not in the
kernel; neither one would bother me.)

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy