Review: Ritchie and Thompson, The UNIX Timesharing System

From: Ian King (iking_at_killthewabbit.org)
Date: Tue Jan 06 2004 - 23:32:47 PST

  • Next message: Sellakumaran Kanagarathnam: "Review: The UNIX Time-Sharing System"

    Ritchie and Thompson describe the salient features of the UNIX operating system,
    developed on the Digital Equipment Corporation (DEC) PDP line of minicomputers.
    This version had been through some field use and revision, and it is significant
    that the version described was rewritten in C; most operating systems of the
    time were written in assembly language. Also noteworthy was the distribution of
    the operating system; the authors claim around one hundred active sites. This
    paper goes into considerable detail on the feature set of UNIX, and while the
    authors discuss some of their experiences in the development process, the result
    is what is emphasized.

    A key intuition was the development of a common namespace for files and many
    other objects in the operating system, all organized hierarchically. At the
    time, DEC operating systems used separate naming conventions for files, devices
    and other system objects. For instance, file systems in RSX-11 (a
    contemporaneous operating system produced by DEC) were flat collections (no
    hierarchy) segregated by user numbers, and devices were named with two letters
    describing the device, followed by a number to allow for multiple units of the
    same kind (e.g. DK0: for an RK05 disk unit). UNIX simplified the naming
    convention by hiding the differences in objects 'under the covers' of the
    operating system - making the computer do the work of distinguishing the objects
    and rationalizing operations on them. Then, too, the I/O design encouraged a
    common set of primitive operations on the objects - read, write, open, close -
    that were rationalized for the type of object by the underlying system. An
    'open' call returned a file descriptor - a small integer, significant to the
    operating system - that could be passed to any number of other function calls
    without regard for whether it represented a file, a device, or even system
    memory. Further, storage could be added to or removed from a hierarchy without
    disturbing the model (and while the system was running), by 'mounting' a storage
    device as a leaf on the hierarchy; that device's file system would be grafted
    onto the existing hierarchy, and accesses could take place with no regard for
    the physical location of a given file.

    Another noteworthy feature, which Ritchie and Thompson describe at length, was
    the choice to have the user interface - the 'shell' - run as a common user
    process. This facilitated the 'timesharing', or multiuser aspect of UNIX, and
    also allowed considerable flexibility in customizing the user experience. The
    shell leveraged the object-agnostic naming convention through command-line
    'pipes' that allowed easy redirection of data streams from or to a device, file
    or program. The shell was the 'standard input' and 'standard output' device, as
    well; programs could easily access the user interface through the file
    descriptor convention, as the descriptors 0 and 1 were assigned to the shell by
    default. The shell was such a fertile workspace that many tools evolved,
    primarily concerned with text manipulation, that could be strung together
    through pipes to create powerful command scripts, directly on the command line.
    (These tools were distributed with the operating system, and are often
    considered an integral part of UNIX.) The redirection mechanism also supported
    the interpretation of text files as command scripts; many UNIX administration
    tools are no more than text files containing command lines.

    The file system was implemented in a fashion that did not require consecutive
    storage of data blocks on a device; instead, the directory structure was
    essentially a database containing one or more names describing a file, and a set
    of pointers to the physical location(s) where the data resided. The many-to-one
    relationship between names and files was created through 'links'; indeed, the
    original name reference to a file could be removed, and the file would persist
    so long as another name reference existed. The scheme partitions file naming
    from file organization, and in practice allows the operating system considerable
    flexibility in maintaining storage effectively. Moreover, it simplified the
    task of incorporating devices into the namespace; device identifiers could be
    stored in the same naming database with only a simple identifier to distinguish
    them from actual files.

    File protection is simple, yet effective. The model allows for individual or
    group privileges for an object (including non-file objects); the groups are
    maintained separately from the objects they may own. The setuid feature is
    particularly clever, controlling not only whether one may access data, but how
    the access is to be accomplished (i.e. through only a suitably authorized
    application). The concept of 'root' privilege is a force for both good and
    evil; while it simplifies administrative tasks, it has also provided the
    opportunity for many security breaches, as once one obtains root privilege, the
    entire system is available without restraint.

    The UNIX approach to processes allowed for both synchronous and asynchronous
    relationships in a hierarchy of processes. This relationship could be created
    by program code or from the command line; in the latter case, programs could be
    executed in the 'background' to complete independently of the shell that spawned
    them.

    UNIX is highly significant because it is a relatively small, concise body of
    software that provides simple metaphors to facilitate easy, effective use of a
    computer - many computers, as the high level language in which it was written
    made for very easy porting to new hardware. It was created by a quite small
    group of people, and was designed on what was incredibly inexpensive hardware at
    the time. Unlike most operating systems of the time (outside the academic
    environment), it was not written by the manufacturer of the hardware. This
    paper likely caused consternation in many software development departments, who
    employed considerably larger staffs of programmers to produce larger bodies of
    code that did not provide the rich feature set and flexibility of UNIX.


  • Next message: Sellakumaran Kanagarathnam: "Review: The UNIX Time-Sharing System"

    This archive was generated by hypermail 2.1.6 : Tue Jan 06 2004 - 23:43:19 PST