Page 16 - DCAP103_Principle of operating system
P. 16
Unit 1: Operating System
it would be possible to execute machine code operations such as modifying registers for Notes
various descriptor tables, or performing operations such as disabling interrupts. The idea
of having two different modes to operate in comes from “with more control comes more
responsibility” a program in supervisor mode is trusted to never fail, because if it does, the
whole computer system may crash.
In a monolithic kernel, the kernel runs in supervisor mode and the applications run in user
mode. Other types of operating systems, like those with an exokernel or microkernel do not
necessarily share this behaviour.
1.4.1 Some Examples from the PC World
Linux and Windows are two operating systems that use supervisor/user-mode. DOS and other
simple operating systems run in supervisor mode permanently, meaning that drivers can be
written directly into software. In user-mode it would be necessary to utilise a system call into
kernel-space (running in supervisor mode) where trusted code in the operation system will
perform the needed task.
Most processors have at least two different modes. The x86-processors have four different modes
divided into four different “rings”. Programs that run in ring0 can do anything with the system
and code that runs in ring3 should be able to fail at any time without any impact at the rest
of the computer system. Ring1 and ring2 is mostly never used, but could be configured with
different levels of access.
Figure 1.4: User and Supervisor Modes
A control program manages the execution of user programs to prevent
errors and improper use of the computer. It is especially concerned with the
operation and control of I/O devices.
1.5 System Calls
In computing, a system call is the mechanism used by an application program to request service
from the operating system based on the monolithic kernel or to system servers on operating
systems based on the microkernel-structure. Timings of requested service have to be strictly
predictable for application in real time systems — those are most advanced and secure. So far,
the only thing we have done was to use well defined kernel mechanisms to register /proc files
and device handlers. This is fine if you want to do something the kernel programmers thought
you had want, such as write a device driver. But what if you want to do something unusual, to
change the behaviour of the system in some way? Then, you are mostly on your own.
LOVELY PROFESSIONAL UNIVERSITY 9