diff options
Diffstat (limited to 'documentation/content/en/books/design-44bsd/_index.adoc')
| -rw-r--r-- | documentation/content/en/books/design-44bsd/_index.adoc | 45 |
1 files changed, 30 insertions, 15 deletions
diff --git a/documentation/content/en/books/design-44bsd/_index.adoc b/documentation/content/en/books/design-44bsd/_index.adoc index bc3b0057ea..08af1a53e6 100644 --- a/documentation/content/en/books/design-44bsd/_index.adoc +++ b/documentation/content/en/books/design-44bsd/_index.adoc @@ -10,6 +10,7 @@ description: Donated by Addison-Wesley, provides a design overview of 4.4BSD, fr trademarks: ["design-44bsd"] bookOrder: 60 tags: ["4.4BSD", "design", "operating system", "BSD", "UNIX"] +layout: single --- = The Design and Implementation of the 4.4BSD Operating System @@ -76,12 +77,15 @@ These system calls are the only interface that processes have to these facilitie Details of the system-call mechanism are given in Chapter 3, as are descriptions of several kernel mechanisms that do not execute as the direct result of a process doing a system call. A _kernel_ in traditional operating-system terminology, is a small nucleus of software that provides only the minimal facilities necessary for implementing additional operating-system services. -In contemporary research operating systems -- such as Chorus <<biblio-rozier, [Rozier et al, 1988]>>, Mach <<biblio-accetta, [Accetta et al, 1986]>>, Tunis <<biblio-ewens, [Ewens et al, 1985]>>, and the V Kernel <<biblio-cheriton, [Cheriton, 1988]>> -- this division of functionality is more than just a logical one. +In contemporary research operating systems -- such as Chorus +crossref:design-44bsd[biblio-rozier, [Rozier et al, 1988]], Mach crossref:design-44bsd[biblio-accetta, [Accetta et al, 1986]], Tunis +crossref:design-44bsd[biblio-ewens, [Ewens et al, 1985]], and the V Kernel crossref:design-44bsd[biblio-cheriton, [Cheriton, 1988]] -- this division of functionality is more than just a logical one. Services such as filesystems and networking protocols are implemented as client application processes of the nucleus or kernel. The 4.4BSD kernel is not partitioned into multiple processes. This basic design decision was made in the earliest versions of UNIX. -The first two implementations by Ken Thompson had no memory mapping, and thus made no hardware-enforced distinction between user and kernel space <<biblio-ritchie, [Ritchie, 1988]>>. +The first two implementations by Ken Thompson had no memory mapping, and thus +made no hardware-enforced distinction between user and kernel space crossref:design-44bsd[biblio-ritchie, [Ritchie, 1988]]. A message-passing system could have been implemented as readily as the actually implemented model of kernel and user processes. The monolithic kernel was chosen for simplicity and performance. And the early kernels were small; the inclusion of facilities such as networking into the kernel has increased its size. @@ -168,10 +172,10 @@ The software that is machine dependent includes |HP/UX compatibility |4,683 |2.3 |=== -<<table-mach-indep>> summarizes the machine-independent software that constitutes the 4.4BSD kernel for the HP300. +crossref:design-44bsd[table-mach-indep, Machine-independent software in the 4.4BSD kernel] summarizes the machine-independent software that constitutes the 4.4BSD kernel for the HP300. The numbers in column 2 are for lines of C source code, header files, and assembly language. Virtually all the software in the kernel is written in the C programming language; less than 2 percent is written in assembly language. -As the statistics in <<table-mach-dep>> show, the machine-dependent software, excluding HP/UX and device support, accounts for a minuscule 6.9 percent of the kernel. +As the statistics in crossref:design-44bsd[table-mach-dep, Machine-dependent software in the 4.4BSD kernel] show, the machine-dependent software, excluding HP/UX and device support, accounts for a minuscule 6.9 percent of the kernel. Only a small part of the kernel is devoted to initializing the system. This code is used when the system is _bootstrapped_ into operation and is responsible for setting up the kernel hardware and software environment (see Chapter 14). @@ -225,7 +229,8 @@ Important components of the kernel state are described in Chapter 4. .Process lifecycle image:fig1.png[Process lifecycle] -The process lifecycle is depicted in <<fig-process-lifecycle>>. +The process lifecycle is depicted in +crossref:design-44bsd[fig-process-lifecycle,Process lifecycle]. A process may create a new process that is a copy of the original by using the _fork_ system call. The _fork_ call returns twice: once in the parent process, where the return value is the process identifier of the child, and once in the child process, where the return value is 0. The parent-child relationship induces a hierarchical structure on the set of processes in the system. @@ -284,7 +289,7 @@ The detailed design and implementation of signals is described in Section 4.7. Processes are organized into _process groups_. Process groups are used to control access to terminals and to provide a means of distributing signals to collections of related processes. A process inherits its process group from its parent process. -Mechanisms are provided by the kernel to allow a process to alter its process group or the process group of its descendents. +Mechanisms are provided by the kernel to allow a process to alter its process group or the process group of its descendants. Creating a new process group is easy; the value of a new process group is ordinarily the process identifier of the creating process. The group of processes in a process group is sometimes referred to as a _job_ and is manipulated by high-level system software, such as the shell. @@ -303,7 +308,7 @@ By changing the process-group identifier of the terminal, a shell can arbitrate This arbitration is called _job control_ and is described, with process groups, in Section 4.8. Just as a set of related processes can be collected into a process group, a set of process groups can be collected into a _session_. -The main uses for sessions are to create an isolated environment for a daemon process and its children, and to collect together a user's login shell and the jobs that that shell spawns. +The main uses for sessions are to create an isolated environment for a daemon process and its children, and to collect together a user's login shell and the jobs that shell spawns. [[overview-memory-management]] === Memory Management @@ -333,8 +338,11 @@ If multiple processes mapped the same file into their address spaces, changes to Ultimately, 4.2BSD was shipped without the _mmap_ interface, because of pressure to make other features, such as networking, available. Further development of the _mmap_ interface continued during the work on 4.3BSD. -Over 40 companies and research groups participated in the discussions leading to the revised architecture that was described in the Berkeley Software Architecture Manual <<biblio-mckusick-1, [McKusick et al, 1994]>>. -Several of the companies have implemented the revised interface <<biblio-gingell, [Gingell et al, 1987]>>. +Over 40 companies and research groups participated in the discussions leading to +the revised architecture that was described in the Berkeley Software +Architecture Manual crossref:design-44bsd[biblio-mckusick-1, [McKusick et al, 1994]]. +Several of the companies have implemented the revised interface +crossref:design-44bsd[biblio-gingell, [Gingell et al, 1987]]. Once again, time pressure prevented 4.3BSD from providing an implementation of the interface. Although the latter could have been built into the existing 4.3BSD virtual-memory system, the developers decided not to put it in because that implementation was nearly 10 years old. @@ -346,7 +354,8 @@ Finally, the virtual-memory system was not designed to support the tightly coupl Attempts to improve the old implementation incrementally seemed doomed to failure. A completely new design, on the other hand, could take advantage of large memories, conserve disk transfers, and have the potential to run on multiprocessors. Consequently, the virtual-memory system was completely replaced in 4.4BSD. -The 4.4BSD virtual-memory system is based on the Mach 2.0 VM system <<biblio-tevanian, [Tevanian, 1987]>>. with updates from Mach 2.5 and Mach 3.0. +The 4.4BSD virtual-memory system is based on the Mach 2.0 VM system +crossref:design-44bsd[biblio-tevanian, [Tevanian, 1987]]. with updates from Mach 2.5 and Mach 3.0. It features efficient support for sharing, a clean separation of machine-independent and machine-dependent features, as well as (currently unused) multiprocessor support. Processes can map files anywhere in their address space. They can share parts of their address space by doing a shared mapping of the same file. @@ -380,7 +389,9 @@ An example is protocol-control blocks that remain throughout the duration of a n Demands for dynamic memory allocation in the kernel have increased as more services have been added. A generalized memory allocator reduces the complexity of writing code inside the kernel. Thus, the 4.4BSD kernel has a single memory allocator that can be used by any part of the system. -It has an interface similar to the C library routines _malloc_ and _free_ that provide memory allocation to application programs <<biblio-mckusick-2, [McKusick & Karels, 1988]>>. +It has an interface similar to the C library routines _malloc_ and _free_ that +provide memory allocation to application programs +crossref:design-44bsd[biblio-mckusick-2, [McKusick & Karels, 1988]]. Like the C library interface, the allocation routine takes a parameter specifying the size of memory that is needed. The range of sizes for memory requests is not constrained; however, physical memory is allocated and is not paged. The free routine takes a pointer to the storage being freed, but does not require the size of the piece of memory being freed. @@ -394,7 +405,8 @@ There are no _access methods_ and no _control blocks_ in a typical UNIX user pro Different programs expect various levels of structure, but the kernel does not impose structure on I/O. For instance, the convention for text files is lines of ASCII characters separated by a single newline character (the ASCII line-feed character), but the kernel knows nothing about this convention. For the purposes of most programs, the model is further simplified to being a stream of data bytes, or an _I/O stream_. -It is this single common data form that makes the characteristic UNIX tool-based approach work <<biblio-kernighan, [Kernighan & Pike, 1984]>>. +It is this single common data form that makes the characteristic UNIX tool-based +approach work crossref:design-44bsd[biblio-kernighan, [Kernighan & Pike, 1984]]. An I/O stream from one program can be fed as input to almost any other program. (This kind of traditional UNIX I/O stream should not be confused with the Eighth Edition stream I/O system or with the System V, Release 3 STREAMS, both of which can be accessed as traditional I/O streams.) @@ -555,7 +567,7 @@ A hierarchy of directories and files is thus formed, and is called a _filesystem [[fig-small-fs]] image:fig2.png[A small filesystem] -a small one is shown in <<fig-small-fs>>. +a small one is shown in crossref:design-44bsd[fig-small-fs, A small filesystem]. Directories may contain subdirectories, and there is no inherent limitation to the depth with which directory nesting may occur. To protect the consistency of the filesystem, the kernel does not permit processes to write directly into directories. A filesystem may include not only plain files and directories, but also references to other objects, such as devices and sockets. @@ -670,7 +682,8 @@ The other part of the local filesystem is the organization and management of the Laying out the contents of files on the storage media is the responsibility of the filestore. 4.4BSD supports three different filestore layouts: * The traditional Berkeley Fast Filesystem -* The log-structured filesystem, based on the Sprite operating-system design <<biblio-rosenblum, [Rosenblum & Ousterhout, 1992]>> +* The log-structured filesystem, based on the Sprite operating-system design + crossref:design-44bsd[biblio-rosenblum, [Rosenblum & Ousterhout, 1992]] * A memory-based filesystem Although the organizations of these filestores are completely different, these differences are indistinguishable to the processes using the filestores. @@ -709,7 +722,9 @@ To get reasonable performance, the client must cache frequently accessed data. The complexity of remote filesystems lies in maintaining cache consistency between the server and its many clients. Although many remote-filesystem protocols have been developed over the years, the most pervasive one in use among UNIX systems is the Network Filesystem (NFS), whose protocol and most widely used implementation were done by Sun Microsystems. -The 4.4BSD kernel supports the NFS protocol, although the implementation was done independently from the protocol specification <<biblio-macklem, [Macklem, 1994]>>. +The 4.4BSD kernel supports the NFS protocol, although the implementation was +done independently from the protocol specification +crossref:design-44bsd[biblio-macklem, [Macklem, 1994]]. The NFS protocol is described in Chapter 9. [[overview-terminal]] |