Chapter Two -- Operating-System Structures -- Lecture Notes

• 2.0 Chapter Objectives
  • Describe OS Services
  • Discuss Design of OS Structure
  • Explain Installation, Customization, and Booting
  
  
• 2.1 Operating-System Services
  • Services typically provided by an operating system include:
    • user interfaces,
    • program execution,
    • control of I/O devices,
    • file-system manipulation,
    • process communication facilities,
    • error detection,
    • resource allocation services,
    • accounting,
    • protection, and
    • security.
  
  
• 2.2 User Operating-System Interface
  • An OS must provide users with an interface for making requests for system services - i.e. command interpreter, shell, or GUI.
  • The user-interface process may perform a requested operations directly or may start up a child process to run a separate program which performs the service. The second approach is more modular.
  • The user-interface is not considered fundamental to the study of operating systems. We study mostly what exists from the system call level and down to the interface with the hardware.
  • To the authors of our text, a user-interface program or other system program that functions above the system-call level is just another user program, and NOT part of the operating system.
  
  
• 2.3 System Calls
  • A system call is like a function call. It is a request for an OS service.
  • Typically the OS is in charge of controlling I/O, so an application that wants to copy or move data in either direction between the RAM and a peripheral device must call upon the OS by making a system call.
  • Typically a computer executes thousands of system calls per second.
  • The run-time support functions in libraries provide the system-call interface for many programming languages - including C and Java.
  • VERY IMPORTANT DETAIL: A process can pass parameters to a system call by leaving them in CPU registers, by leaving them in a RAM block (pointed to by an address in a register), or by pushing them onto the runtime stack.
  
  
• 2.4 Types of System Calls
  • There are system calls for:
    • process control,
    • file manipulation,
    • device manipulation,
    • information maintenance, and
    • communication.
  • Process control:
    • halt process,
    • dump process,
    • abort process,
    • load process,
    • execute process,
    • create process,
    • get and set process attributes (e.g. priority or time limit),
    • terminate process,
    • wait,
    • wait event,
    • signal event,
    • acquire lock on shared data,
    • release lock on shared data,
    • allocate and free memory.
    
    In the MS-DOS style of process control, processes run 'one at a time' - there is no multiprogramming. In fact, the OS overwrites much of itself when it loads a user process to execute. The OS reloads itself after a user process exits.
    
    Flavors of unix like Free BSD employ a user shell capable of spawning (via fork and exec system calls) a child process that may excecute concurrently with the parent shell. There is no overwriting of the OS associated with loading a user process, as is the case with MS-DOS. Many processes typically execute concurrenlty.
    
    
  • File Management:
    • create file,
    • delete file,
    • open file,
    • close file,
    • read file,
    • write file,
    • move file,
    • copy file,
    • reposition file,
    • get & set file attributes (e.g. name, type, protection codes, accounting info).
  • Device Management:
    • request device (important for dealing with contention & deadlock),
    • release device (important for dealing with contention & deadlock),
    • read from device,
    • write to device,
    • reposition device,
    • get & set device attributes,
    • logically attach or detach device.
    
    The term device may refer to real physical devices such as hard drives, or abstract (virtual) devices such as files.
    
    
  • Information Maintenance:
    • get or set time or date,
    • get or set system data (e.g. number of current processes or amount of free memory),
    • get or set process, file, or device attributes,
    • process tracing and profiling capabilities.
  • Communications:
    • get host or process identifier,
    • create/open or delete/close communications connection,
    • accept communications connection,
    • wait for request for communications connection,
    • send or receive message,
    • transfer status information,
    • attach or detach remote devices,
    • shared memory create or attach
    
    The style of communication may be via message passing or via shared memory. Message passing is easy to implement but may be slow. When available, communication via shared memory is fast but requires sophisticated protection and synchronization schemes.
    
    
  • Protection:
    • get permissions,
    • set permissions,
    • allow user, and
    • deny user.
  
  
• 2.5 System Programs
  • Typically there are system programs that organize access to system calls for the convenience of users. There may be system programs for
    • file management,
    • status information,
    • file modification,
    • programming-language support,
    • program loading and execution, and/or
    • communication.
  • Because of the heavy use of API's, system programs, and higher level applications, most computer users are seldom if ever directly concerned with the system-call interface.
  
  
• 2.6 Operating-System Design and Implementation
  • An OS is software and design of the OS is a problem in software engineering. The principles of good software design certainly apply to OS development.
  • Designers should try to be guided by the anticipated needs of the intended users of the system.
  • Separation of Policy from Mechanism is an important design principle important for flexibility.
  • Typically A few parts of an OS have to be written in assembly language.
  • However modern operating systems are written almost entirely in a high-level programming language such as C. Advantages: code is developed faster; is smaller, easier to understand, debug and change; and easier to port.
  • There are some things that just can't be done with high-level language statements, for example some device-driver code and instructions that save and restore register values.
  • There was a time when writing more of the code in assembly could be justified because assembly programmers could use 'tricks' that made routines run faster by some constant factor compared with compiled high level code. Modern optimizing compilers have eliminated that advantage almost entirely, although there are still a few bottlenecks in systems that are 'hand-coded' in assembly language in order to achieve 'the absolute maximum' efficiency - e.g. the authors mention memory managers and CPU schedulers in this regard.
  • As the authors say: "As is true in other systems, major performance improvements in operating systems are more likely to be the result of better data structures and algorithms than of excellent assembly-language code."
  
  
• 2.7 Operating-System Structure
  • As with any software project, an OS should be designed with appropriate attention to information hiding and modularity.
  • However, well-known operating systems such as MS-DOS and the original unix had monolithic designs -- i.e. they were NOT modular.
  • One way to achieve the goals of information hiding and modularity is to create a layered design, in which each layer depends only on the functionality of layers beneath it. A layered system may be built from the bottom up. If there are problems, one can always be certain that they are in the layer currently under construction. The main disadvantages of this approach are first the difficulty of conceiving of layers without any circular dependencies, and second the fact that each layer adds overhead which slows down the operation of the system.
  • There is a microkernel approach to OS design. The idea is to remove all functions possible from the kernel and implement them as system and user-level applications. For example, file systems can be implemented at the user level.
  • Typically the remaining microkernel provides some process control, memory management, and process communication facilities.
  • Microkernel systems tend to be bug-free, secure, easy to modify and easy to port.
  • The main disadvantage seems to be the overhead created by the need for user-level parts of the system to communicate through the kernel.
  • The design style that is currently popular is similar to the microkernel except that it employs dynamically loadable user-level modules which are not constrained to communicate through the kernel.
  
  
• 2.8 Virtual Machines
  • It is difficult, but not impossible, to design an OS so that it makes available several virtual operating system environments on a single computer. For example you can have a microkernel system on which there are running a virtual Windows XP computer, a virtual Linux computer, and a virtual Macintosh. These can operate as if they were three completely independent computers.
  • Designers of operating systems can use the virtual computer idea to test their designs. If a design fails, it is very unlikely that other VM's hosted on the same hardware will crash or be affected in any way. Even though developers may be experimenting with the OS on a system, users can continue getting their work done using a stable version of the OS.
  • In many cases money can be saved because the need is reduced for a multiplicity of computers running different operating systems.
  • If a virus attacks on virtual computer it is very unlikely to spread to the others.
  • One can also test application software on different OS's by using a system that offers all the OS's as virtual machines.
  • The Java virtual machine is another example - here the object is portability - a java program can run safely (relatively) on any computer that has the JVM.
  
  
• 2.9 Operating-System Debugging
  • When an OS crashes typically the contents of kernel memory are saved in a special file or disk partition. By studying these 'core (memory) dumps' and log files, system designers can glean information useful for debugging OS code.
  • It is very important to study existing systems in order to learn how to build better systems. For example, this was one of the 'secrets of success' of the developers of Berkeley Unix. It is important to build system-monitoring code into the OS. Such systems produce "traces" of their operation - they write records of all 'interesting' system events in log files which can be analyzed later.
  • There are also online monitoring tools - applications that are able to display performance characteristics of a running system - such as the percentage of CPU time used by each process, average length of I/O queues, current amount of free primary memory, and so forth.
  
  
• 2.10 Operating-System Generation
  • Systems have to be configured for the specific site to which they are targeted. For example, we perform system genearation when we put a new host online, providing at that time, for example, a hostname, host IP address, router IP address.
  • Other SYSGEN operations possible: disk partitioning, installation of device drivers, choice of CPU-scheduling algorithm, and setting of the maximum number of processes to be supported.
  • The SYSGEN information may be incorporated into the source code for the OS, and a custom version of the OS then compiled.
  • Another option is for the system to be pre-compiled and the SYSGEN information saved in the form of tabular information in files, accessed and utilized by the pre-compiled OS in order to achieve the desired customization effects. For example the system can read its hostname and default router froma configuration file. Scripts written during the SYSGEN can be executed each time the computer boots in order to perform custom setups.
  • Tables can determine which of certain dynamically loadable modules are to be loaded at boot time.
  • SYSGEN maybe followed by a linking, but not compiling step, so that certain modules such as drivers are incorporated into a permanent executable image of the kernel.
  
  
• 2.11 System Boot
  • Modern computers have ROM that begins executing automatically at system start-up time.
  • The ROM runs diagnostics, initializes the hardware, and loads the OS from disk. (It might load a secondary boot program, which in turn loads the OS.)
  • In some small devices, the entire OS may be in ROM or EPROM.