OS6 - Solutions Manual !!!!!!!!!!!!!
120 pág.

OS6 - Solutions Manual !!!!!!!!!!!!!


DisciplinaSistemas Operacionais I8.350 materiais171.621 seguidores
Pré-visualização31 páginas
in the kernel, such as the /tmp-
filesystem (a fast virtual memory based file-system found on some UNIX systems).
Note that the complexity of managing page faults while running kernel code is not an
issue here. The Linux kernel code is already able to deal with page faults: it needs to be
able to deal with system calls whose arguments reference user memory which may be
paged out to disk.
20.7 In Linux, shared libraries perform many operations central to the operating system. What
is the advantage of keeping this functionality out of the kernel? Are there any drawbacks?
Explain your answer.
Answer: There are a number of reasons for keeping functionality in shared libraries
rather than in the kernel itself. These include:
Reliability. Kernel-mode programming is inherently higher risk than user-mode pro-
gramming. If the kernel is coded correctly so that protection between processes is
enforced, then an occurrence of a bug in a user-mode library is likely to affect only
the currently executing process, whereas a similar bug in the kernel could conceiv-
ably bring down the entire operating system.
Performance. Keeping as much functionality as possible in user-mode shared libraries
helps performance in two ways. First of all, it reduces physical memory consump-
tion: kernel memory is non-pageable, so every kernel function is permanently res-
98 Chapter 20 The Linux System
ident in physical memory, but a library function can be paged in from disk on de-
mand and does not need to be physically present all of the time. Although the library
function may be resident in many processes at once, page sharing by the virtual
memory system means that at most once it is only loaded into physical memory.
Second, calling a function in a loaded library is a very fast operation, but calling a
kernel function through a kernel system service call is much more expensive. Enter-
ing the kernel involves changing the CPU protection domain, and once in the kernel,
all of the arguments supplied by the process must be very carefully checked for cor-
rectness: the kernel cannot afford to make any assumptions about the validity of
the arguments passed in, whereas a library function might reasonably do so. Both
of these factors make calling a kernel function much slower than calling the same
function in a library.
Manageability. Many different shared libraries can be loaded by an application. If new
functionality is required in a running system, shared libraries to provide that func-
tionality can be installed without interrupting any already-running processes. Sim-
ilarly, existing shared libraries can generally be upgraded without requiring any
system down time. Unprivileged users can create shared libraries to be run by their
own programs. All of these attributes make shared libraries generally easier to man-
age than kernel code.
There are, however, a few disadvantages to having code in a shared library. There are
obvious examples of code which is completely unsuitable for implementation in a li-
brary, including low-level functionality such as device drivers or file-systems. In gen-
eral, services shared around the entire system are better implemented in the kernel if they
are performance-critical, since the alternative\u2014running the shared service in a separate
process and communicating with it through interprocess communication\u2014requires two
context switches for every service requested by a process. In some cases, it may be ap-
propriate to prototype a service in user-mode but implement the final version as a kernel
routine.
Security is also an issue. A shared library runs with the privileges of the process calling
the library. It cannot directly access any resources inaccessible to the calling process, and
the calling process has full access to all of the data structures maintained by the shared
library. If the service being provided requires any privileges outside of a normal process\u2019s,
or if the data managed by the library needs to be protected from normal user processes,
then libraries are inappropriate and a separate server process (if performance permits) or
a kernel implementation is required.
20.8 What are three advantages of dynamic (shared) linkage of libraries compared to static
linkage? What are two cases where static linkage is preferable.
Answer: The primary advantages of shared libraries are that they reduce the memory
and disk space used by a system, and they enhance maintainability.
When shared libraries are being used by all running programs, there is only one instance
of each system library routine on disk, and at most one instance in physical memory.
When the library in question is one used by many applications and programs, then the
disk and memory savings can be quite substantial. In addition, the startup time for run-
ning new programs can be reduced, since many of the common functions needed by that
program are likely to be already loaded into physical memory.
Maintainability is also a major advantage of dynamic linkage over static. If all running
programs use a shared library to access their system library routines, then upgrading
those routines, either to add new functionality or to fix bugs, can be done simply by
replacing that shared library. There is no need to recompile or relink any applications;
Answers to Exercises 99
any programs loaded after the upgrade is complete will automatically pick up the new
versions of the libraries.
There are other advantages too. A program that uses shared libraries can often be adapted
for specific purposes simply by replacing one or more of its libraries, or even (if the sys-
tem allows it, and most UNIXs including Linux do) adding a new one at run time. For
example, a debugging library can be substituted for a normal one to trace a problem in an
application. Shared libraries also allow program binaries to be linked against commercial,
proprietary library code without actually including any of that code in the program\u2019s final
executable file. This is important because on most UNIX systems, many of the standard
shared libraries are proprietary, and licensing issues may prevent including that code in
executable files to be distributed to third parties.
In some places, however, static linkage is appropriate. One example is in rescue envi-
ronments for system administrators. If a system administrator makes a mistake while
installing any new libraries, or if hardware develops problems, it is quite possible for the
existing shared libraries to become corrupt. As a result, often a basic set of rescue utilities
are linked statically, so that there is an opportunity to correct the fault without having to
rely on the shared libraries functioning correctly.
There are also performance advantages that sometimes make static linkage preferable in
special cases. For a start, dynamic linkage does increase the startup time for a program,
as the linking must now be done at run-time rather than at compile-time. Dynamic link-
age can also sometimes increase the maximum working set size of a program (the total
number of physical pages of memory required to run the program). In a shared library,
the user has no control over where in the library binary file the various functions reside.
Since most functions do not precisely fill a full page or pages of the library, loading a
function will usually result in loading in parts of the surrounding functions, too. With
static linkage, absolutely no functions that are not referenced (directly or indirectly) by
the application need to be loaded into memory.
Other issues surrounding static linkage include ease of distribution: it is easier to dis-
tribute an executable file with static linkage than with dynamic linkage if the distributor
is not certain whether the recipient will have the correct libraries installed in advance.
There may also be commercial restrictions against redistributing some binaries as shared
libraries. For example, the license for the UNIX \u201cMotif\u201d graphical environment allows
binaries using Motif to be distributed