[IOS] Ch2 System Structures #2

 

Types of System Calls

• Process control
• end, abort
• load, execute
• create process, terminate process
• get process attributes, set process attributes
• wait for time
• wait event, signal event
• allocate and free memory

• File management
• create file, delete file
• open, close
• read, write, reposition
• get file attributes, set file attributes

• Device management
• request device, release device
• read, write, reposition
• get device attributes, set device attributes
• logically attach or detach devices

• Information maintenance
• get time or date, set time or date
• get system data, set system data
• get process, file, or device attributes
• set process, file, or device attributes

• Communications
• create, delete communication connection
• send, receive messages
• transfer status information
• attach or detach remote devices

• Protection

Process Control

A running program needs to be able to halt its execution either normally (end) or abnormally (abort). If a system call is made to terminate the currently running program abnormally, or if the program runs into a problem and causes an error trap, a dump of memory is sometimes taken and an error message generated.
The dump is written to disk and may be examined by a debugger - a system program designed to aid the programmer in finding and correcting bugs - to determine the cause of the problem.
Under either normal or abnormal circumstances, the operating system must transfer control to the invoking command interpreter. The command interpreter then reads the next command.
Some systems allow control cards to indicate special recovery actions in case
an error occurs.
A control card is a batch-system concept. It is a command to manage the execution of a process. If the program discovers an error in its input
and wants to terminate abnormally, it may also want to define an error level.
More severe errors can be indicated by a higher-level error parameter. It is then possible to combine normal and abnormal termination by defining a normal termination as an error at level 0. The command interpreter or a following program can use this error level to determine the next action automatically.
A process or job executing one program may want to load and execute another program. An interesting question is where to return control when
the loaded program terminates.
This question is related to the problem of whether the existing program is lost, saved, or allowed to continue execution concurrently with the new program.

• Control returns to the existing program when: 
• the new program terminates: 
• save the memory image of the existing program
• created a mechanism for one program to call another program. 
• both programs continue concurrently:
• created a new job or process to be multiprogrammed.
• There is a system call specifically for this purpose (create process or submit job)

Having created new jobs or processes, we may need to wait for them
to finish their execution. We may want to wait for a certain amount of time
to pass (wait time); more probably, we will want to wait for a specific event to
occur (wait event). The jobs or processes should then signal when that event
has occurred (signal event). Quite often, two or more processes may share
data.
To ensure the integrity of the data being shared, operating systems often
provide system calls allowing a process to lock shared data, thus preventing
another process from accessing the data while it is locked.
Typically such system calls include acquire lock and release lock. System calls of these types, dealing with the coordination of concurrent processes.

• MS-DOS: 
• single-tasking system
• has a command interpreter that is invoked when the computer is started
• uses a simple method to run a program and does not create a new process
• loads the program into memory, writing over most of itself to give the program as much memory as possible
• sets the instruction pointer to the first instruction of the program
• program runs, and either an error causes a trap, or the program executes a system call to terminate
• error code is saved in the system memory for later use
• the small portion of the command interpreter that was not overwritten resumes execution. 
• Its first task is to reload the rest of the command interpreter from disk
• The command interpreter makes the previous error code available to the user or to the next program.

• FreeBSD (derived from Berkly UNIX):
• multitasking system
• When a user logs on to the system, the shell of the user's choice is run. 
• the command interpreter may continue running while another program is executed
• To start a new process, the shell executes a fork() system call
• Then the selected program is loaded into memory via an exec() system call, and the program is executed.
• the shell waits for the process to finish or runs the process "in the background." 
• bg: it cannot receive input directly from the keyboard, because the shell is using this resource. I/O is therefore done through files or through a CUI interface. 
• the user is free to ask the shell to run other programs, to monitor the progress of the running process, to change that program's priority, and so on. 
• When the process is done, it executes an exit () system call to terminate, returning to the invoking process a status code of 0 or a nonzero error code. This status or error code is then available to the shell or other programs.

Communication

There are two common models of interprocess communication: the message -passing model and the shared-memory model.

• Message-passing model
• communicating processes exchange messages with one another to transfer information.
• Messages can be exchanged between the processes either directly or indirectly through a common mailbox. 
• Before communication can take place, a connection must be opened. 
• each process has a process name, and this name is translated into an identifier by which the operating system can refer to the process. 
• The recipient process usually must give its permission for comnmnication to take place with an accept connection call.
• The source of the communication, known as the client, and the receiving daemon, known as a server, then exchange messages by using read message and write message system calls. 
• The close connection call terminates the communication.

• shared-memory model:
• processes use shared memory create and shared memory attach system calls to create and gain access to regions of memory owned by other processes.
• normally, the operating system  prevent one process from accessing another process's memory. 
• requires that two or more processes agree to remove this restriction.
• exchange information by reading and writing data in the shared areas. 
• The form of the data is determined by the processes and are not under the operating system's control. 
• The processes are also responsible for ensuring that they are not writing to the same location simultaneously. 

Both of the models just discussed are common in operating systems, and most systems implement both.
Message passing is useful for exchanging smaller amounts of data, because no conflicts need be avoided. It is also easier to implement than is shared memory for inter computer communication.
Shared memory allows maximum speed and convenience of communication, since it can be done at memory transfer speeds when it takes place within a computer. Problems exist, however, in the areas of protection and  synchronization between the processes sharing memory.

System Programs

System programs, also known as system utilities, provide a convenient environment for program development and execution.Some of them are simply user interfaces to system calls; others are considerably more complex. They can be divided into these categories:

• File management: 
• These programs create, delete, copy, rename, print, dump, list, and generally manipulate files and directories.

• Status information:
• Some programs simply ask the system for the date, time, amount of available memory or disk space, number of users, or similar status information. 
• Others are more complex, providing detailed performance, logging, and debugging information. 
• format and print the output to the terminal or other output devices
  or files or display it in a window of the GUI. 
• Some systems also support a which is used to store and retrieve configuration information.

• File modification:
• Several text editors may be available to create and modify the content of files stored on disk or other storage devices. 
• There may also be special commands to search contents of files or perform transformations of the text.

• Programming-language support:
• Compilers, assemblers, debuggers, and interpreters for common programming languages (such as C, C++, Java, Visual Basic, and PERL) are often provided to the user with the operating system.

• Program loading and execution:
• Once a program is assembled or compiled, it must be loaded into memory to be executed. The system may provide absolute loaders, relocatable loaders, linkage editors, and overlay loaders. 
• Debugging systems for either higher-level languages or machine language are needed as well.

• Communications:
• These programs provide the mechanism for creating virtual comcections among processes, users, and computer systems. 
• allow users to send messages to one another's screens, to browse Web pages, to send electronic-mail messages, to log in remotely, or to transfer files from one machine to another.

Operation System Design and Implement

In this section, we discuss problems we face in designing and implementing an operating system. There are, of course, no complete solutions to such problems, but there are approaches that have proved successful.

Design Goals

• user goals
• The system should be convenient to use, easy to learn and to use, reliable, safe, and fast. 

• system goals
• A similar set of requirements can be defined by those people who must design, create, maintain, and operate the system. The system should be easy to design, implement, and maintain; and it should be flexible, reliable, error free, and efficient. 

•  no unique solution to the problem of defining the requirements for an operating system. 

• Mechanisms determine how to do something, policies decide what will be done
• The separation of policy from mechanism is a very important principle, it allows maximum flexibility if policy decisions are to be changed later
   

Operating System Structure

Simple Structure

• MS-DOS – written to provide the most functionality in the least space
• Not divided into modules
• Although MS-DOS has some structure, its interfaces and levels of functionality are not well separated
• application programs are able to access the basic I/O routines to write directly to the display and disk drives. (為了要較好的效能)
• 安全性較低（對惡意程式來說十分脆弱）
• causing entire system crashes when user programs fail
• limited by the hardware of its era because the Intel 8088 for which it was written provides no dual mode and no hardware protection, the designers of MS-DOS had no choice but to leave the base hardware accessible.

 

• original UNIX operating system
•  initially was limited by hardware functionality
• consist of two separable parts:
• kernel
• system programs
• kernel consists of everything below the system-call interface and
  above the physical hardware
• kernel  provides the file system, CPU scheduling, memory management, and other operating-system functions; a large
  number of functions for one level
• This monolithic structure was difficult to implement and maintain.

Layered Approach

• The operating system is divided into a number of layers (levels), each built on top of lower layers. 
• The bottom layer (layer 0), is the hardware; the highest (layer N) is the user interface.
• With modularity, layers are selected such that each uses functions (operations) and services of only lower-level layers
• The main advantage of the layered approach is simplicity of construction and debugging.
• each layer hides the existence of certain data structures, operations, and hardware from higher-level layers.

Microkernels

• Moves as much from the kernel into “user” space

• Communication takes place between user modules using message passing
• if the client program wishes to access a file, it must interact with the file server. The client program and service never interact directly. Rather they communicate indirectly by exchanging messages with the microkernel.

• Benefits:
• Easier to extend a microkernel
• All new services are added to user space and consequently do not require modification of the kernel
• 更新 kernel 其實就是把記憶體裏面的資料更換，但因為相依問題有時候需要重新開機（若可以 handle 則不需重開）
• changes tend to be fewer, because the microkernel is a smaller kernel
• Easier to port the operating system to new architectures
• More reliable (less code is running in kernel mode)
• More secure

• Detriments:
• Performance overhead of user space to kernel space communication

Kernel Modules

Perhaps the best current methodology for operating-system design involves
using object-oriented programming techniques to create a modular kernel.

• Most modern operating systems implement kernel modules
• Uses object-oriented approach
• Each core component is separate
• Each talks to the others over known interfaces
• Each is loadable as needed within the kernel

• Overall, similar to layers but with more flexible

• Are kernel modules isolated from each other? (just like user processes are isolated from each other)

• module 和 module 之間可能會需要資料共享 or communication (考量到效能的問題)，除此之外，以目前 x86 的架構也做不到

Reference:  
Operating System Concepts 8th, by Silberschatz, Galvin, Gagne
Wikipedia