Sunday, 16 September 2012

Introduction to Unix

Introducing Unix

Why an Operating System (OS)

  • OS interacts with hardware and manages programs.
  • Programs not expected to know which hardware they will run on.
  • Must be possible to change hardware without changing the programs.
  • Programs can’t manage themselves.
  • OS provides a safe environment for programs to run.
For reasons of portability, programs must be independent of the hardware the run on. They should access the hardware by making calls to the operating system. Different flavors of Unix MUST use the same calls even though the calls may be implemented differently.
Because an OS like Unix allows multiple programs to access the CPU, the OS needs to manage the CPU, memory and control registers to enable switching from one program to another. The OS must also provide a safe environment so one program has no access to the memory used by another program.

How a Program Runs on a Computer

  • OS loads program from disk and allocates memory and CPU.
  • Instructions in program are run on CPU and OS keeps track of last instruction executed.
  • If a program needs to access the hardware, OS does the job on its behalf.
  • OS saves the state of the program if program has to leave CPU temporarily.
  • OS cleans up memory and registers after process has completed execution.
Need to mention that even in a time-sharing system like Unix, a program may still suspend execution even if its allocated time slice has not expired.
Program A vacates the CPU and makes way for another program B when A needs to wait for some event or does something (like reading the disk) that doesn’t require the CPU in any way. However, some tasks like finding and sorting files are CPU-intensive. In such situations, a program will vacate the CPU only at the scheduled time.

Running Multiple Programs

Multiple programs can be in memory.
Multiple users can run programs.
One user can run multiple programs.
Multiprogramming allows speedy resumption of execution of a program that is already in memory; repeatedly loading a program from disk is expensive.
The multiuser feature is a direct outcome of multiprogramming. It allows the machine to serve multiple users. Students need to be aware of the diverse nature of user requirements. All programs generally don’t need the services of the CPU at a given instant of time. For instance, a user editing a file with vi (or emacs) is actually using the CPU for a very small fraction of time. So, it makes sense for the OS to make the CPU available to other programs while a vi session is on.
The same argument holds even when a single user is working on the machine. Since programmers spend most of the time in editing programs, adequate time is always available for other programs to run while an editing session is in progress. For instance, a disk scanning or sort operation doesn’t impact an editing session in a significant manner. A user can concurrently run multiple programs provided that they ALL don’t ALWAYS require the CPU.

Key Concepts

  • Everything in the system is represented as a file.
  • Work gets done by processes.
  • All Unix systems use the same system calls. (POSIX Standard)
A file is a component of a larger hierarchical structure called the file system. What is not obvious from these illusions is that a user also has a location in this file system (Current Working directory). Because both a file and a user have a location, a file’s location can be specified in two ways:
  1. With respect to the root (top) of the file system (/), absolute path name
  2. Relative to the user’s location. relative path name
For a command to run, the kernel creates a process for that command using the information provided in the executable file.

Unix Architecture: The Kernel

  • Program always resides in memory.
  • Has direct access to the hardware.
  • Handles file I/O.
  • Manages processes.
  • Only one copy shared by all users.
The kernel is the first program to be loaded in memory. It then creates the processes that are necessary to keep the system going. User programs access portions of kernel code when they need to perform a basic task like reading a file or creating a process. In fact, it’s the kernel that performs all the basic tasks of the OS, so we can refer to the kernel as the basic OS.
File handling and process management are done using system calls, which could be approximated to C functions. In fact, these calls are available to a C programmer also.

Unix Architecture: The Shell

  • A program or command invoked only when the user logs in.
  • Accepts user input, examines and rebuilds the command line.
  • Makes calls to the kernel for all other functions.
  • At least one shell is invoked by every user.
  • User has a choice of shells.
Even though the shell is also a program like cat, it is unique in that it always runs at the user’s terminal. If the user does no work, the shell has to remain idle. The shell is a command interpreter and this job on a Unix system can be quite complex. The shell can open files (by making calls to the kernel) and make commands write to these files (like in who > foo).
The shell has to act before the command is actually executed. Consider the example cat foo* where the shell first expands foo* to all files in the current directory that begin with the name foo. So cat never gets to see a file named foo* but only the files made available by interpretive work done by the shell.

Character Versus Graphical User Interface.

  • Character User Interface
    • Input device (e.g., Keyboard is used to issue a command)
    • Command line Interface
  • Graphical User Interface
    • Input is taken from a point-and-click device.

Unix Philosophy

  1. Small is beautiful
  2. Each program does one thing well
  3. Build a prototype as soon as possible
  4. Choose portability over efficiency
  5. Store numerical data in flat ASCII files
  6. Use software leverage to your advantage
  7. Use shell scripts to increase leverage and portability
  8. Avoid captive user interfaces
  9. Make every program a filter

The Development of the UNIX Operating System

  • AT&T Bell Laboratory
    • AT&T UNIX Version 1 through UNIX Version 6
    • Ken Thompson, Dennis Richie
  • Developed and Written in C
  • Releases distributed as C Source Code
  • AT&T System V
    • Released in 1983
  • Berkley Software Distributions
    • 3BSD and 4BSD
  • The History of Shells
    • Bourne Shell, C Shell, Korn Shell, BASH Shell.
  • Linux with help from GNU
Fragmented Unix Versions
POSIX and the Single Unix Specification have specified a common set of interfaces that Unix-branded systems have to conform to. Wherever possible, we should use POSIX-compliant features and options. For instance, some systems offer tail -r to present lines in reverse order, but POSIX doesn’t require Unix systems to support it. So this feature must not be used in a portable application.
Some systems have two or more versions of the same command; Solaris has a separate set of POSIX-compliant versions in /usr/xpg4/bin.

No comments:

Post a Comment