Learning Objectives
After completing this chapter, you will be able to:
Understand the internal working of UNIX OS
What is UNIX?
UNIX is an operating system which was first developed in the 1960s, and has been under constant development ever since. . It is a stable, multi-user, multi-tasking system for servers, desktops and laptops. UNIX is highly portable across hardware since it is written in C language.
UNIX allows only needed modules to be loaded in memory (modularity).It has an inverted tree like file structure, with files and directories created within the file structure. Each file can be protected using read, write and execute permissions for the user, group and others(security).. UNIX uses TCP/IP protocol. CAD/CAM applications best perform in a UNIX system, with its varied support for graphic cards.
UNIX systems also have a graphical user interface (GUI) similar to Microsoft Windows which provides an easy to use environment. However, knowledge of UNIX is required for operations which are not covered by a graphical program, or when there is no windows interface available, for example, in a telnet session.
Types of UNIX
There are many different versions of UNIX, although they share common similarities. The most popular varieties of UNIX are Sun Solaris, GNU/Linux, and MacOS X.
Here in the School, we use Solaris on our servers and workstations, and Fedora Core Linux on the servers and desktop PCs.
History of UNIX
1969: Ken Thompson, Dennis Ritchie started working on a multi-user OS on PDP-7, Bell Labs.
1970: OS named as UNIX 1973: OS rewritten in C
1975: First Version of Berkeley Software Distribution (BSD) 1982: AT&T announced UNIX System III, first public release.
1983: AT&T announced UNIX System V, the first supported release. Installed base 45,000.
1986: 4.3BSD released, including internet name server. Installed base 2, 50,000. 1987: System V Release 3 introduced. Around 7, 50,000 installations.
1988: Open Software Foundation formed.
1989: System V Release 4 ships unifying System V, BSD and Xenix. 1.2 million installations.
its varied support for graphic cards.
Layered Architecture
UNIX is a layered operating system. The innermost layer is the hardware that provides the
services for the OS. The operating system, referred to in UNIX as the kernel, interacts directly with the hardware and provides the services to the user programs. Most well written user programs are independent of the underlying hardware, making them readily portable to new systems.
Fig 9.1: Layered Architecture of the UNIX System
You can have many users logged into a system simultaneously, each running many programs. It's the kernel's job to keep each process and user separate and to regulate access to system
hardware, including cpu, memory, disk and other I/O devices.
Kernel
The kernel of UNIX is the hub of the operating system. It provides the most basic interface
between the machines itself and the rest of the operating system. The kernel is responsible for the management of the central processor. The kernel includes the dispatcher to allocate the central processor, to determine the cause of an interrupt and initiate its processing, and some provision for communication among the various system and user tasks currently active in the system.
The main functions of the kernel are to provide:
A mechanism for the creation and deletion of processes,
CPU scheduling, memory management, and device management for these processes, Synchronization tools so that the processes can synchronize their actions,
Communication tools so that processes can communicate with each other.
UNIX System Calls
The UNIX operating system has two separable parts: the kernel and the service programs. User programs interact with the kernel through a set of standard system calls. These system calls request services to be provided by the kernel. Such services would include accessing a file: open close, read, write, link, or execute a file; starting or updating accounting records; changing ownership of a file or directory; changing to a new directory; creating, suspending, or killing a process; enabling access to hardware devices; and setting limits on system resources.
The kernel provides control of file system, CPU scheduling, memory management, and other operating system functions through system calls. System calls define the programmer interface to operating system; the set of systems programs commonly available defines the user interface.
System calls also provide the interface between a running program and the operating system. The C language allows system calls to be made directly. Typical system calls are,
_open open a device or file
_close close a device or file
_read read from a device or file
_write write to a device or file
_getch read a character from a
terminal
_putch write a character to the terminal
_ioctl control/set device parameters
Header Files:
Header files define how a system call works. A header file contains a definition of the system call, and the parameters (variables) required by the call, and the parameters returned by the system call.
UNIX User Interface
In the last few years, there has been extensive work to improve the user interface to UNIX. The most dramatic effort has been the addition of windowing interfaces on top of UNIX such as X- windows, Suntools, NextStep, Motif, OpenLook, etc. These windowing interfaces do not change UNIX itself but are built on top of UNIX to provide a more intuitive interface to UNIX. Each of the different user interfaces has some advantages and some disadvantages. Currently intensive development effort is being done on all of these Graphical User Interfaces (GUIs). Even with all of these efforts, UNIX is weak in the end-user interface area.
UNIX Shell
The shell is your interface to the operating system. It acts as a command interpreter; it takes each command and passes it to the operating system. It then displays the results of this operation on your screen.
An interpreter operates in a simple loop: It accepts a command, interprets the command, executes the command, and then waits for another command. The shell displays a "prompt," to notify you that it is ready to accept your command. This is depicted in Fig. 9.2.
Fig 9.2: Shell Command Loop
Each shell command consists of a command name, followed by command options (if any or desired) and command arguments (if any or desired). The command name, options, and
arguments, are separated by a blank space. A program is referred to as a process while the kernel is running it. The kernel can run the same shell program (or any other program) simultaneously for many users on a UNIX system, and each running copy of the program as a separate process.
When you execute a non built-in shell command, the shell asks the kernel to create a new sub process (called a "child" process) to perform the command. The child process exists just long enough to execute the command. The shell waits until the child process finishes before it will accept the next command.
There are several shells in widespread use. The most common ones are described below. Bourne shell (sh)
o Original UNIX shell written by Steve Bourne of Bell Labs. Available on all UNIX systems. Does not have the interactive facilities provided by modern shells such as the C shell and Korn shell. The Bourne shell does provide an easy to use language with which you can write shell scripts.
C shell (csh)
o Written at the University of California, Berkley. As it name indicates, it provides a C like language with which to write shell scripts.
Korn shell (ksh)
o Written by David Korn of bell labs. It is now provided as the standard shell on UNIX systems. Provides all the features of the C and TC shells together with a shell programming language similar to that of the original Bourne shell.
TC Shell (tcsh)
o Available in the public domain. It provides all the features of the C shell together with EMACS style editing of the command line.
Bourne Again Shell (bash)
o Public domain shell written by the Free Software Foundation under their GNU initiative. Ultimately it is intended to be a full implementation of the IEEE POSIX Shell and Tools specification. Widely used within the academic community. Provides all the interactive features of the C shell (csh) and the Korn shell (ksh). Its programming language is compatible with the Bourne shell (sh).
Logging in and Logging out
Logging in to a UNIX system requires a username and a password. The person who creates the account, usually the administrator, assigns a Username and a password. The username must be unique. $ is the default prompt of the shell.
To change your password, type the command passwd
After you have logged in. The system will ask for the old password. Then it will ask for the new password. You will be asked to confirm your new password, to make sure that you didn't mistype. When you're ready to quit, type the command
Basic Form of UNIX Commands
The basic form of a UNIX command is: commandname [-options] [arguments]
The command name is the name of the program to execute. The command options, usually indicated by a dash, allow to alter the behavior of the command. The arguments are the names of files, directories, or programs that the command needs to access.
The square brackets ([ and ]) signify optional parts of the command that may be omitted. You can abort the current command by typing Control-C.
Getting Help on Commands
$ man command: To get the default manual entry of the command.
Example:
$ man passwd
To get the manual entry on the command – passwd.
Simple Shell Commands
$ pwd
o To print the current working directory $ date
o To display the current system date and time $ date “+%H”
o To display only the hour $ who
o To list the logged in users of the system $ ls
o To list the names of files and directories $ ls -l
o To list the names of files and directories in long format $ ls -R
o To recursively list the names of files and directories starting from the current directory
$ mkdir Telcom_proj
o To create a directory Telcom_proj in the current directory $ cd Telcom_proj
o To change the working directory to Telcom_proj $ rmdir Telcom_proj
o To remove the directory Telcom_proj; The directory should be empty $ cat abc.txt
$ cp file1.txt file2.txt
o To copy the contents of the file, file1.txt to file, file2.txt $ rm file1.txt
o To delete the file file1.txt
Standard Input, Standard Output and Standard Error
Input/Output redirection is based on the UNIX standard I/O concept. Each command uses three I/O streams: standard input, standard output and standard error. The standard I/O streams determine where input is read from and output is written to.
I/O Stream Abbreviation Description
UNIX commands receive information from the user via standard input. By default, standard input is the keyboard. Standard Input stdin
UNIX commands send information to the user via standard output. By default, standard output is the terminal (i.e. written to the screen). Standard
Output stdout
UNIX commands send error messages to the user via standard error. By default, standard error is the terminal. Standard Error stderr
Example
$ rm -i fhere fnothere remove fhere? y
rm: fnothere: No such file or directory
rm is used to remove two files, fhere and fnothere. The -i option is used for interactive deletion.
Redirecting Standard Input
When programs require input from the user, it is usually entered from the keyboard. However, it can be read from a file by following the command with a less than sign (<) followed by a filename. command < filename
This is useful with UNIX commands that do not open files. For example, the tr (translate characters) command is used to transform one string into another.
Example
$ tr "[:lower:]" "[:upper:]" < file1
Will change all characters in file1 from lower case to upper case and print the results to the screen.
Redirecting Standard Output
The output from a command can be saved in a file by following any command with a greater than sign (>) followed by a filename.
command > filename
Example
$ cat file1 file2 > file3
Saves the contents of file1 and file2 into a new file named file3. The output from the cat command is redirected from the terminal to the file, file3. If file3 already exists then it will be overwritten.
$ cat file2 >> file3
Appends the contents of file2 to file3. The result is file3 contains the contents of file1 followed by the contents of file2.
Standard input and standard output can be redirected in the same command.
$ tr "[:lower:]" "[:upper:]" < file1 > file2
Will change all characters in file1 from lower case to upper case and save the results in the file, file2.
Piping
Piping directs the standard output of one UNIX command into the standard input of another UNIX command. Piping is done by separating two commands with a pipe character (|).
cmd1 | cmd2
Example
$ ls | more
Sends output from the ls command to the more command. This is useful if a directory listing scrolls off the screen.
UNIX Process Management
The Process ID (PID)
Every process running on UNIX server has a unique number called the process id abbreviated as PID. When you start a process in the background, the system displays the PID associated with the background process. For example,
$ longcmd & [1] 310
The PID associated with longcmd is 310. All processes have a PID. $ ps
Will list the status of all processes being executed
Process Context
Process context includes the following:
User Level Context : Program text, data and stack (dynamic allocation of variables) Register Level Context : Value of Program Counter (PC), Contents of the processors
registers, Value of the variables System Level Context :
o Static: Process table entry, uarea, Per Process region table;
o Dynamic: User Stack which typically contains data such as subroutine parameter, return address, and temporary variables; Kernel stack which typically contains temporary data such as subroutine parameter, return address, and temporary variables of system calls
Process table
The O/S maintains information about each process in a process table. Entries in this table are often called process control blocks and must contain information about
process state memory state resource state for each process.
Process state includes the
value of each register program counter stack pointer
state of the process (runnning, runnable, blocked) process ID of itself, its parent, etc.
elapsed time.
Memory state
Pointers to the various memory areas used by the program need to be kept, so that they can be relocated back as needed.
Resource state
The process will generally have files open in particular directory, have a certain user ID, etc. The information about these will need to be stored also.
In UNIX each process has a file table. The first entry in this (file descriptor zero) is for the processes' standard input, the second entry is for standard output, the third for standard error. Additional entries are made when the process opens more files.
Fig. 9.3: Process Implementation Scheme
Figure 9.3 depicts a simple process implementation scheme. There are two processes, A and B, each with its own instructions, data and context, stored in main memory. The OS maintains, also in memory, a list of pointers to the above processes, and perhaps some additional information for each of them.
The content of a ``current process'' location identifies which process is currently being executed. The processor registers then contain data relevant to that particular process. Among them are the base and top addresses of the area in memory reserved to the process: an error condition would be trapped if the program being executed tried to write in a memory word whose address is outside those bounds.
Process States and Transitions
When a system boots UNIX, it creates a single process called ``init''. This init acts as the root of the process tree. The init forks a set of copies of itself, one for each terminal line that is connected to it. Each one of these, type the login message and then blocks waiting for terminal input.
When the user name and password are typed, init checks that the user is valid, and if so changes to the user's home directory, resets the user ID of the process to the user, and ``exec''s a shell. At this point the init for that terminal line has been replaced by the login shell for that user. The user does whatever they want to do, and eventually logs out.
Logging out terminates the login shell. In the meantime, the init at the top of the process tree has done a wait, waiting on any of its children. The login shell is in fact a direct child of this top level init because it came from exec-ing a child. So when the shell terminates, the top level init wakes up. The top level init then forks a new init for that terminal line and starts a wait again, for another child to terminate.
When a process is created, it goes through a series of states as depicted in Figure 9.3. The following list contains the complete set of process states.
1. The process is executing in user mode. 2. The process is executing in kernel mode.
3. The process is ready to run as soon as the kernel schedules it. 4. The process is sleeping and resides in main memory.
5. The process is ready to run, but the swapper (process 0) must swap the process into main memory before the kernel can schedule it to execute.
6. The process is sleeping, and the swapper has swapped the process to secondary storage to make room for other processes in main memory.
7. The process is returning from the kernel to user mode, but the kernel preempts it and does a context switch to schedule another process.
8. The process is newly created and is in a transition state; the process exists; but it is not ready to run, nor is it sleeping. This state is the start state for all process.
9. The process executed the exit system call and is in the zombie state. The process no longer exists; but it leaves a record containing an exit code. The zombie state is the final state of a process.
First, the process gets created with the fork () system call and it enters the bubble diagram at bubble number 8. Then the process enters state 3 or 5 depending on whether there is enough memory or not. Let’s say there is enough memory and it is in state 3. That state is the ready to run in memory, where the process is waiting in line to get its time quantum for the CPU. When the scheduler chooses it based on its scheduling algorithm, the process enters the kernel running state where it finishes its part of the fork () system call.
Fig. 9.4: Process State Transition Diagram
After that, the process can go into the user mode until its time quantum is up. At that time, the scheduler will pick another process to run, and the previous process goes back to the end of the