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 (for billing or usage research),
    • protection, and
    • security.
  
  
• 2.2 User and 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 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.
  • Typically, there is a number associated with each system call. When the trap caused by the system call puts the OS into the CPU, the OS looks up the system call in a table maintained by the OS, using the system call number to index the appropriate entry of the table. The table entry tells the OS which code routine to run. The OS executes that code routine, and the routine performs the service required by the system call.
  • 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
    • communication, and
    • protection.
    
    
  • Process control:
    • end, abort
    • load, execute
    • create & terminate process,
    • get or set process attributes,
    • wait for a specific amount of time,
    • wait for or signal an event,
    • acquire or release lock on 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 command interpreter part of the OS overwrites much of itself when it loads a user process to execute. The remaining part of the command processor reloads the rest of the command processor after the 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 and delete file,
    • open and close file,
    • read and write file,
    • move and 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 and 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 system data (e.g. number of current processes or amount of free memory),
    • dump 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,
    • write/send or read/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 and set permissions, and
    • allow 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,
    • communications and/or
    • background services (daemons).
    
    
  • Most computer users seldom, if ever, directly use system calls. They rely on system calls indirectly, through the use of APIs, system programs, and higher-level applications
  
  
• 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 a design principle important for flexibility. It allows the system to be configured in different ways according to policy, for example a mechanism that supports different CPU scheduling policies.
  • 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. Actually several different high level languages may be used to implement various parts of an operating system. 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 (e.g. message-passing with kernel serving as go-between).
  • 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.
  • Actual operating systems are usually structured as some sort of hybrid of the structures described above. For example, Windows is largely monolithic, but supports user-mode subsystems and dynamically loadable kernel modules.
  
  
• 2.8 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.9 Operating-System Generation
  • Systems have to be configured for the specific site to which they are targeted. For example, we perform system generation 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 from a 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 may be 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.10 System Boot
  • Modern computers have ROM that begins executing automatically at system start-up time.
  • The ROM boot program will typically run diagnostics, initialize the hardware, and load the OS from disk (or it might load a secondary boot program from disk, which in turn loads the OS from disk, or there might be both secondary and tertiary boot programs on disk).
  • In some small devices, the entire OS may be in ROM or EPROM.