Os Concepts - Ryerson University

download report

Transcript Os Concepts - Ryerson University

OS Concepts
Computer Software:
1-system programs (OS)
2-application programs
•Os controls all computer resources and provides
the base upon which the application programs can
be written
•Os is the software layer that is on top of the
hardware to manage all parts of the system, and
present the user with interface or virtual machine
that is easier to understand and program.
OS Concepts
A Computer System:
OS Concepts
• The Macroprogram is located in the ROM and
directly control the hardware
• Some Computers such as RISC does not have
microprogram and hardware executes the
machine languages directly.
• OS hides the hardware complexity:
all details of moving heads, and so on…
• OS runs in the kernel mode or supervisor mode.
User can change his password but can not write
his/her own disk interrupt handler.
OS as a virtual machine
OS present a user with the extended machine that
hides the truth about hardware. For example
reading/writing from a floppy disk requires to
• 16 commands
• 13 parameters packed in 9 bytes
• Address of disk block
• Recording mode, gap spacing, deleted data
address mark
• Whether the motor is on or off and etc.
OS as a Resource Manager
• Managing processors, memories , timers , disks,
mice, network interfaces, laser printers and other
• Bringing the order to the chaos: for example
buffering all output of three programs before
sending them to the printer.
• Managing multiple users when sharing hardware
and information (files, database and etc.)
History of Operating Systems
OS historically have been closely tied to the
architecture of the computers on which,
they run. So looking at generation of the
computers enables us to see what their
OS were like.
• The first generation: Vacuum tubes and
plugboards (1945-55)
• The second generation: Transistors and
batch systems (1955-65)
An early batch system
Structure of a FMS job (Fortran Monitor
• The third generation: ICs and
multiprogramming: (1956-1980)
•Spooling and time sharing
History of OS
The forth generation: Personal Computers (1980present)
• Workstations and network operating systems
and distributed systems
• MSDOS, UNIX (supports IEEE POSIX standard
system calls interface), WINDOWS
• MINIX is Unix like operating system written in C
for educational purposes (1987)
• Linux is the extended version of MINIX
OS concepts “review”
• System calls: Interface between user and Os.
Extended instructions provided by OS.
For example Minix system calls:
• Dealing with processes
• Dealing with file system
• Processes: are used to get the work done. A
program in execution. Associated with address
space, program counters , stack pointers and
hardware registers.
• Process table: A link list for each existing
process that contains all information
about the process, other than the contents
of its own address.
• When the process is suspended all of its
information is saved in process table.
• Command interpreter (Shell) reads the
user commands from terminal to create a
• A process can create child processes and
communicate with them (interprocess
• The main method for storing data.
Directory is used to keep the files and FFS
uses it for cylinder grouping technique in
Unix ( we will study in great details).
• In spite of process hierarchy, file hierarchy
can be deep and long-lived
• Typically parent process can access the
child process but files and directories can
be read by others not just the owner.
• Root directory and path (INODE in Unix)
• Files and directories are protecting by assigning
each a protection code
9 bit in Minix/Unix for example: rwxr-x—x
owner can read, write or execute
other group members can read or execute
everyone else can only execute
• If access to a file is permitted system returns an
integer (file descriptor) otherwise an error code
• Mounting the files is the ways to deal with the
files in removable medias (floppy and CDs).
• Floppy in mounted to b. If b had files they would
not be accessible. So b should be empty.
• Pipe is the way to make the
communication between two processes
looks like file read and write.
• Shell is a command interpreter (not part of
OS) such as sh, csh in Unix to process the
user commands like:
sort < file1 > file2
or cat file1 file2 file3 | sort > /dev/lp &
to concatenate file1&2& 3 and sort and
put the result at /dev/lp. & makes the job to
run in the background mode
System Calls
• Can be called from C or other programming
language to enter the kernel (API in Windows)
• For example when a user program is in the user
mode and needs a system service such as
reading form a file by
count=read(fd,buffer,nbytes) switches to kernel
• The system calls provide process mng. , file
mng., directory and file system management
and other services.
OS structure
If we look inside OS, there are four designs:
1- Monolithic systems:
• Collection of the procedures each of
which calling other ones (The Big Mess)
• No information hiding. Ever procedure is
visible to other procedures.
• System calls switch to kernel mode (see
• In monolithic model for system calls there
are service procedures using utility
OS Structure
2- Layered systems
• It is generalization of monolithic approach
• In the user level , they should not worry
about process, memory, console or I/O
managements. These jobs are done by
lower layers.
• “THE “ was the first layered system
developed in the Netherlands by
• Structure of THE operating system
OS Structure
3- Virtual machines
• Several virtual machines are simulated in this model
(providing virtual 8086 on Pentium to be able to run
MSDOS programs)
• VM provides several virtual OSs such as single user,
interactive and etc. all run on Bare hardware.
OS Structure
4- Client-Server Model
• Moving most of the code up into the higher layers
made the kernel to be minimal and only responsible
for communication between clients and servers.
OS Structure
• Advantage of this system is adaptability to use in
distributed systems.
• Disadvantage is doing OS functions ( e.g.
loading physical I/O device registers) in the user
space is difficult.
OS Structure
There are two ways to solve this problem
• To have some critical server processes run
in the kernel with complete access to
hardware but still communicating with
other normal processes.
• Enhance the kernel to provides these
tasks but server decides how to use it
(Splitting policy and mechanism)