54394gt@hocda.UUCP (G.TOMASEVICH) (02/06/84)
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). Now the only use of supervisor mode on the PDP-11 is to accommodate a kernel that outgrew the kernel-mode address space. At that point, UNIX already started becoming a pig, and now look where it is! You need a VAX, huge disks, etc. to run everything. The shell was outside the kernel because of the address space limit. The question: where should one draw the line on putting shell, terminal features, editor, etc when the machine has a huge address space? This leads to Rob Pike's discussion.
guy@rlgvax.UUCP (Guy Harris) (02/07/84)
> 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
gwyn%brl-vld@sri-unix.UUCP (02/09/84)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> I don't think the shell is outside the kernel just because of address space limitations; instead, that is a very good design and I have made good use of it in the past by substituting other login shells for users tailored to the applications (such as menu-driven interfaces for data acquisition systems).
gwyn%brl-vld@sri-unix.UUCP (02/09/84)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> The early UNIXes for memory-managed (KT11) PDP-11s were available for the PDP-11/40 as well as the PDP-11/45. The /40 architecture was similar to the more familiar /34 in that it had Kernel & User modes but not separate Instruction & Data spaces. Two "modes" are both necessary and sufficient for controlled resource sharing with the typical memory manager architecture.
ron%brl-vgr@sri-unix.UUCP (02/10/84)
From: Ron Natalie <ron@brl-vgr> RSX-11M+ (version 3.2) uses supervisor mode and split I&D in a dumb way. -Ron