UNIX was developed at Bell Labs in the early 1970s. The first version was written by Ken Thompson in assembler for the PDP- 7 minicomputer. This was soon followed by a version for the PDP-ll, written in a new language called C that was devised and implemented by Dennis Ritchie. In 1974, Ritchie and Thompson published a landmark paper about UNIX (Ritchie and Thompson, 1974). For the work described in this paper they were later given the prestigious ACM Turing Award (Ritchie, 1984; Thompson, 1984). The publication of this paper stimulated many universities to ask Bell Labs for a copy of UNIX. Since Bell Labs' parent company, AT&T, was a regulated monopoly at the time and was not permitted to be in the computer business, it had no objection to licensing UNIX to universities for a modest fee.
In one of those coincidences that often shape history, the PDP-11 was the computer of choice at nearly all university computer science departments, and the operating systems that came with the PDP-l1 were widely regarded as being dreadful by professors and students alike. UNIX quickly filled the void, not in the least because it was supplied with the complete source code, so people could, and did, tinker with it endlessly.
One of the many universities that acquired UNIX early on was the University of California at Berkeley. Because the complete source code was available, Berkeley was able to modify the system substantially. Foremost among the changes was a port to the V AX minicomputer and the addition of paged virtual memory, the extension of file names from 14 characters to 255 characters, and the inclusion of the TCP/IP networking protocol, which is now used on the Internet (largely due to the fact that it was in Berkeley UNIX).
While Berkeley was making all these changes, AT&T itself continued to develop UNIX, leading to System III in 1982 and then System V in 1984. By the late 1980s, two different, and quite incompatible, versions of UNIX were in widespread use: Berkeley UNIX and System V. This split in the UNIX world, together with the fact that there were no standards for binary program formats, greatly inhibited the commercial success of UNIX because it was impossible for software vendors to write and package UNIX programs with the expectation that they would run on any UNIX system (as was routinely done with MS-DOS). After much bickering, a standard called POSIX (Portable Operating System-IX) was created by the IEEE Standards Board. POSIX is also known by its IEEE Standards number, PlO03. It later became an International Standard.
The POSIX standard is divided into many parts, each covering a different area of UNIX. The first part, PlO03.l, defines the system calls; the second part, PlO03.2, defines the basic utility programs, and so on. The PlO03.l standard defines about 60 system calls that all conformant systems must support. These are the basic calls for reading and writing files, creating new processes, and so on. Nearly all UNIX systems now support the PlO03.l system calls. However many UNIX systems also support extra system calls, especially those defined by System V and/or those in Berkeley UNIX. Typically these add up to perhaps 100 system calls to the POSIX set. The operating system for the UltraSPARC II is based on System V and is called Solaris. It also supports many of the Berkeley system calls.
A rough breakdown of the Solaris system calls by category is given in Fig. 629. The file and directory management system calls are largest and the most important categories. Most of these come from PIO03.l. A relatively large fraction of the others are derived from System V.
|File management||Open, read, write, close, and lock files|
|Directory management||Create and delete directories; move files around|
|Process management||Spawn, terminate, trace, and signal processes|
|Memory management||Share memory among processes; protect pages|
|Getting/setting parameters||Get user, group, process ID; set priority|
|Dates and times||Set file access times; use interval timer; profile execution|
|Networking||Establish/accept connection; send/receive message|
|Miscellaneous||Enable accounting; manipulate disk quotas; reboot the system|
Figure 6-29. A rough breakdown of the UNIX system calls.
One area that is largely due to Berkeley UNIX rather than System V is networking. Berkeley invented the concept of a socket, which is the endpoint of a network connection. The four-pin wall plugs to which telephones can be connected served as the model for this concept. It is possible for a UNIX process to create a socket, attach to it, and establish a connection to a socket on a distant machine. Over this connection it can then exchange data in both directions, typically using the TCP/IP protocol. Since networking technology has been in UNIX for decades and is very stable and mature, a substantial fraction of the servers on the Internet run UNIX.
Since there are many implementations of UNIX, it is difficult to say much about the structure of the operating system since everyone is somewhat different from all the others. However, in general, Fig. 6-30 applies to most of them. At the bottom, there is a layer of device drivers that shield the file system from the bare hardware. Originally, each device driver was written as an independent entity, separate from all the others. This arrangement led to a lot of duplicated effort, since many drivers must deal with flow control, error handling, priorities, separating data from control, and so on. This observation led Dennis Ritchie to develop a framework called streams for writing drivers in a modular way. With a stream, it is possible to establish a two-way connection from a user process to a hardware device and to insert one or more modules along the path. The user process pushes data into the stream, which then is processed or transformed by each module until it gets to the hardware. The inverse processing occurs for incoming data.
Figure 6-30. The structure of a typical UNIX system.
On top of the device drivers comes the file system. It manages file names, directories, disk block allocation, protection, and much more. Part of the file system is a block cache, for holding the blocks most recently read in from disk, in case they are needed again soon. A variety of file systems have been used over the years, including the Berkeley fast file system (McKusick et al., 1984), and log-structured file systems (Rosenblum and Ousterhout, 1991; and Seltzer et al., 1993).
The other part of the UNIX kernel is the process management portion. Among its various other functions, it handles IPC (InterProcess Communication), which allows processes to communicate with one another and synchronize to avoid race conditions. A variety of mechanisms are provided. The process management code also handles process scheduling, which is based on priorities. Signals, which are a form of (asynchronous) software interrupt, are also managed here. Finally, memory management is done here as well. Most UNIX systems support demandpaged virtual memory, sometimes with a few extra features, such as the ability of multiple processes to share common regions of address space.
From its inception, UNIX has tried to be a small system, in order to enhance reliability and performance. The first versions of UNIX were entirely text-based, using terminals that could display 24 or 25 lines of 80 ASCII characters. The user interface was handled by a user-level program called the shell, which offered a command line interface. Since the shell was not part of the kernel, adding new shells to UNIX was easy, and over time a number of increasingly sophisticated ones were invented.
Later on, when graphics terminals came into existence, a windowing system for UNIX, called X Windows, was developed at M.I.T. Still later, a full-fledged GUI (Graphical User Interface), called Motif, was put on top of X Windows. In keeping with the UNIX philosophy of having a small kernel, nearly all the code of X Windows and Motif runs in user mode, outside the kernel.
from Andrew S. Tanenbaum, Structured Computer Organization, Fourth Ed., Prentice-Hall, 1999. (ISBN 0-13-095990-1)