Information Technology Reference
In-Depth Information
topic. In this chapter, we focused parts of the UNIX interface because it is both
compact and powerful. A key aspect of the UNIX interface are that creating a
process (with fork) is separate from starting to run a program in that process
(with exec); another key feature is the use of kernel buffers to decouple reading
and writing data through the kernel.
Operating systems use the system call interface to provide services to appli-
cations and to aid in the internal structuring of the operating system itself. Al-
most all general-purpose computer systems today have a user-level shell and/or
a window manager that can start and manage applications on behalf of the
user. Many systems also implement parts of the operating system as user-level
services accessed through kernel pipes.
As we've noted, a trend is for applications to become mini-operating sys-
tems in their own right, with multiple users, resource sharing and allocation,
untrusted third-party code, processor and memory management, and so forth.
The system call interfaces for Windows and UNIX were not designed with this
in mind, and an interesting question is how they will change to accommodate
this future of powerful meta-applications.
In addition to the fine-grained sandboxing and process creation we described
at the end of the last chapter, a trend is to re-structure the system call inter-
face to make resource allocation decisions explicit and visible to applications.
Traditionally, operating systems make resource allocation decisions | when to
schedule a process or a thread, how much memory to give a particular applica-
tion, where and when to store its disk blocks, when to send its network packets
| transparently to the application, with a goal of improving end user and over-
all system performance. Applications are unaware of how many resources they
have, appearing to run by themselves, isolated on their own (virtual) machine.
Of course, the reality is often quite different. An alternate model is for
operating systems to divide resources among applications and then allow each
application to decide for itself how best to use those resources. One can think
of this as a type of federalism. If both the operating system and applications
are governments doing their own resource allocation, they are likely to get in
each other's way if they aren't careful. As a simple example, consider how a
garbage collector works; it assumes it has a fixed amount of memory to manage.
However, as other applications start or stop, it can gain or lose memory, and if
the operating system does this reallocation transparently, the garbage collector
has no hope of adapting. Later in the topic, we will see examples of this same
design pattern in many different areas of operating system design.
Exercises
For convenience, the exercises from the body of the chapter are repeated here.
1. Can UNIX fork return an error? Why or why not?
