This course is run at the The University of Nottingham within the School of Computer Science & IT. The course is run by Graham Kendall (EMAIL : gxk@cs.nott.ac.uk)
This section is based on (Tanenbaum, 1992), pages 12-18.
As you might expect we use an operating system (in terms of using the OS within a program) via a well defined interface. That is, we make calls to the operating system so that it will perform some task for us. These "entries" into the OS are called system calls. Through these system calls we can manipulate various types of objects. During this course we will be looking at some of these objects in detail (e.g. processes) but we briefly introduce them here.
One of the key tasks for an operating system is to run processes. For now, we can consider a process as a running program with all the other information that is needed to control its execution (e.g. program counter, stack, registers, file pointers etc.).
If the CPU is running one process and, for whatever reason, another process
now needs to run, the operating system must save the details of the currently
running process and start the new process from exactly the same point as it
was left.
All the data for a process is normally held in a process table. This is a data structure that contains a list of active processes which the operating system uses to decide which process to run next and to restore a process to the state it was in before it was stopped from running.
A process may create a child process. For example, if we issue a command from the command shell (one process), this will create another process to execute the command. This can lead to a tree like structure of processes. When that command finishes the child process will issue a system call to destroy itself.
One of the main tasks of an operating system is to schedule all the processes which are currently competing for the CPU.
Processes may also communicate with other processes. This might sound simple but, as we shall see, later in the course, this leads to all sorts of complications which the operating system must handle.
Another broad class of system calls relate to the file system.
We said above that one of the tasks of an operating system is to hide the complexities of the hardware. In order to do this system calls must be provided to (for example) create files, delete files, move files, rename files, copy files, open files, close files, read files, write files etc. etc.
As an example of this abstraction, consider that some operating systems provide you with different types of file. You may be able to open a file in text mode or in binary mode. The way you open the file determines how the data is delivered to your program. In fact, the underlying mechanisms which position the read/write head, access the data and return it to the operating system are the same no matter what type of file you are reading. It is only when it is delivered to your program does the data get interpreted in the way the program is expecting.
To take this one stage further, many operating systems provide a special file called standard input and standard output. These default to data typed at the terminal and data sent to the terminal. We consider them as files but there is obviously a lot more going on in the operating system that allows us to visualise a terminal as a file.
There is even the concept of a process being an input file for another process, which acts as if it is writing to a file. This is normally presented to us as a pipe. For example, in MS-DOS if you type
DIR | SORT
It pipes the output from the DIR command to the SORT command, so that the display comes out sorted (in fact, it sorts the lines in alphabetical order - and might not be what you expect).
Similar to pipes is redirection. This allows the output from a program to be redirected to a file. For example
DIR > dir.txt
Will redirect the output of the DIR command from the standard output (the screen)
to the file called dir.txt.
(If you have never used MS-DOS (or UNIX) you might like to experiment with redirection
- also try ">>" and "<").
The whole point of mentioning standard input, standard output, pipes and redirection is to demonstrate that the operating system is hiding a lot of complexity from us as well as providing us with many features which we might find useful.
Many file systems also support the concept of directory (or folder) hierarchies. That is, there is a top level view of the file system and by creating folders you can build a tree (conceptually) which represents your view of the data. Therefore, the file system must provide system calls to maintain these directory structures.
When discussing processes we said that it is possible to build a tree of processes, in the same way we can build a directory hierarchy. But there are many differences between these trees.
· Process trees are normally short lived. Directory trees can last for years.
· Files (assuming access rights are granted) can be maintained by any user of the system. A process can only be controlled by its parent.
· Directories (and files) can have access rights associated with them. Processes have no such information.
· Directories (and files) can be accessed in a number of ways (e.g. relative or absolute pathnames). Process tress have no such concept.
Access to the operating system is done through system calls. Each system call
has a procedure associated with it so that calls to the operating system can
be done in a familiar way.
When you call one of these procedures it places the parameters into registers
and informs the operating system that there is work to be done. Notifying the
operating system is done via a TRAP instruction (sometimes known as a kernel
call or a supervisor call). This instruction switches
the CPU from user mode to kernel (or supervisor)
mode. In user mode certain instructions are unavailable to the programs. In
kernel mode all the CPU instructions are available.
The operating system now carries out the work, which includes validating the parameters. Eventually, the operating system will have completed the work and will return a result in the same way as a user written function written in a high level language.
An example of an operating system call (via a procedure) is
count = read(file, buffer, nbytes);
You can see that it is just the same as calling a user written function in a language such as C.
The operating system is the mechanism that carries out the system calls requested
by the various parts of the system. Tools such as compilers, editors etc. are
not part of the operating.
Similarly, the shell is not part of the operating system. The shell is the part of (for example) UNIX and MS-DOS where you can type commands to the operating system and receive a response. You may also hear the shell get called the Command Line Interpreter (CLI) or the "C" prompt. However, it is worth mentioning the shell as it makes heavy use of operating system features and is a good way to experiment.
We have already seen one example of a command line (DIR > dir.txt).
A more complicated command (in UNIX this time) could be
cat file1 file2 file3 | sort > /dev/lp &
This command concatenates three files and pipes them to the sort program. It
then redirects the sorted file to a line printer.
The ampersand at the end of the command instructs UNIX to issue the command as a background job. This results in the command prompt being returned immediately, whilst another process carries out the requested work.
You can appreciate, by looking at the above command that there will be a series of system calls to the operating system in order to satisfy the whole request.
| Last Page | Back to Main Index | Next Page |
Last Updated : 08/01/2002