Problem

How to design a interative-use system with easy use (i.e., write, test, and run programs) given the hardware constraint?

System designs

Architecture

File System

• Untyped data (byte oriented)

  • Structure of files is controlled by the programs which uses them, not by the system

• Hierarchical name space

  • Strict hierarchy across directories

    • The directory structure is constrained to have the form of a rooted tree (i.e., each directory must appear as an entry in exactly one other, which is its parent)

  • Disallowing multiple links to directories

    • Advantages: easier search; easier garbage collection (no cycles)

• Directories are files

  • A directoy behaves exactly like an ordinary file execpt that it cannot be written on by unprivileged programs, so that the system controls the contents of directories; anyone with proper permission can read a directory just like ordinary files.

  • Linking: same nondirectory file may appear in several directories under possibly different names

• Treating I/O devices as files

  • Special files exist for each communication line, each disk, each tape drive, and for physical core memory

  • Advantages:

    • File and device I/O are as similar as possible
    • File and device names have the same syntax and meaning
    • Special files are subject to the same protection mechanism as regular files

• Mount

  • Removable storage; expand storage

    • mount replaces a leaf of the hierarchy tree (the ordinary file) by a whole new subtree (the hierarchy stored on the removable volume)

  • No cross-volume links allowed

• Set-User-ID (right amplification)

  • Setuid (set user ID on execution) permits users to run certain programs with escalated privileges (i.e., execute a program as someone else)
  • Example: when a user wants to change their password, they run the passwd command. The passwd program is owned by the root account and marked as setuid, so the user is temporarily granted root access for that very limited purpose. Since user id of invoker is known, it's passwd program responsibility to make sure the invoker's proper behavior.

• File descriptor

  • A small integer used to identify the file in subsequent calls to read, write

  • Used as a index to a system table that contains file's device, i-number, and read/write pointer

  • Filter programs (e.g., ls | pr -2 | opr) do not know the name of input or output files

  • "Handle with access rights” (that is a capability, which is an abstraction that makes protected sharing easier); it is a capability because the right can be transferred to other processes that want to access the file

• Implementation

  • A directory contains file name and a pointer to file; the pointer is the i-number of the file. When the file is accessed, its i-number is used as an index into a system table (i-list) stored in a known part of the device on which the directory resides.

  • i-number is used as a index to find corresponding entry inode in i-list; inode contains description of file

  • A small (nonspecial) file fits into eight or fewer blocks; in this case the addresses of the blocks themselves are stored. For large (nonspecial) files, each of the eight device addresses may point to an indirect block of 256 addresses of blocks constituting the file itself. These files may be as large as \(8 \cdot 256 \cdot 512\)

  • ... more on paper

Process Management

• An image is a computer execution environment. It includes a core image (contains three segments: code, heap, stack), general register values, status of open files, current directory, and the like. An image is the current state of a pseudo computer.

• A process is the execution program of an image.

• Building blocks

  • Fork, exec, wait

  • File I/O structure

    • Fork'd child shares parent's open files; have indenpendent copy of the original core image

    • Pipes: not a completely general mechanism since the pipe must be set up by a common ancestor of the processes involved (working mechanism see paper)

    • Standard I/O

      • Programs executed by the shell start off with two open files which have file descriptors 0 (stdin) and 1 (stdout)

      • Enables redirection and pipelines easily

    • Shell

      • bg execution

      • initialization: last step in the initialization of UNIX is creation of a single process and the invocation of init; init creates child processes which will later become shells.

Remarks

• On treating I/O devices as files advantages: (1) seems useful but high-performance implementation tend to treat e.g., network I/O differently from disk. (2) seems useless ("ioctl" interface for device-specific functionality is terrible); (3) is compelling

• "There have been three versions of UNIX." Fred Brooks is right

• I learn some new usage in UNIX (e.g., pr - paginates its input with dated headings; ed as a editor; (date; ls) > x - use parentheses)