OS6 - Solutions Manual !!!!!!!!!!!!!
DisciplinaSistemas Operacionais I8.350 materiais • 171.621 seguidores
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