Download Operating Systems Lab.

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Berkeley Software Distribution wikipedia , lookup

Library (computing) wikipedia , lookup

Mobile operating system wikipedia , lookup

Smallfoot wikipedia , lookup

Copland (operating system) wikipedia , lookup

OS 2200 wikipedia , lookup

RSTS/E wikipedia , lookup

Plan 9 from Bell Labs wikipedia , lookup

Booting wikipedia , lookup

Distributed operating system wikipedia , lookup

Burroughs MCP wikipedia , lookup

VS/9 wikipedia , lookup

Security-focused operating system wikipedia , lookup

DNIX wikipedia , lookup

Windows NT startup process wikipedia , lookup

Process management (computing) wikipedia , lookup

Spring (operating system) wikipedia , lookup

CP/M wikipedia , lookup

Paging wikipedia , lookup

Unix security wikipedia , lookup

Transcript
Operating Systems Lab.
(#1)
University of Tehran – ECE Dept.
Fall 2005
Reza Shokri
[email protected]
Outline









The Evolution of Linux
Kernel Organization
Linux Versions
The Booting Procedure
Process and Resource Management
Memory Management
Device Management
File Management
An Overview of the Unix Filesystem
Operating Systems Lab - UT ECE Dept
Fall 2005
2/40
The Evolution of Linux

By 1985, two primary versions of UNIX were running
on many different hardware platforms:





The main line version from AT&T Bell Labs (System V)
Alternative version from the University of California at
Berkeley (BSD UNIX)
By 1989, a committee had been formed to develop a
standardized system call interfaces. The result was
and API, a system call interface, called POSIX.
Linux developed by “Linus Trovald” in 1991
It inherits from UNIX architecture

BUT, not completely
Operating Systems Lab - UT ECE Dept
Fall 2005
3/40
Kernel Organization





UNIX kernels, is designed and implemented
as a monolithic kernel.
Data structures for each aspect of the kernel
are generally accessible to all other aspects
of the kernel.
Device Drivers
Modules
Interrupts
Operating Systems Lab - UT ECE Dept
Fall 2005
4/40
Kernel Organization
Operating Systems Lab - UT ECE Dept
Fall 2005
5/40
Kernel Organization


Trap
System call





For a system call, F, a stub procedure is used to invoke F (The
stub is also named F)
The stub is linked into the (user-space) calling program.
When a process executes the call to F at runtime, control is
transferred to the stub procedure rather than directly to the
kernel.
The stub procedure validates the parameter values being
passed to the kernel procedure.
The stub procedure executes a trap instruction that switches
the CPU to supervisory mode. It then branches to the entry
point for the target kernel function.
Operating Systems Lab - UT ECE Dept
Fall 2005
6/40
Linux Versions
Operating Systems Lab - UT ECE Dept
Fall 2005
7/40
The Booting Procedure




The BIOS first runs the manufacturer’s hardware
booting sequence by executing the Power-On Self
Test (POST). The POST performs various diagnostic
tests to check presence of resources.
The BIOS launches the first stage boot loader on
the MBR of the primary hard disk.
The first stage boot loader loads itself into memory
and launches the second stage boot loader from the
/boot/ partition.
The second stage boot loader loads the kernel into
memory, which in turn loads any necessary modules
and mounts the root partition read-only.
Operating Systems Lab - UT ECE Dept
Fall 2005
8/40
The Booting Procedure



The kernel transfers control of the boot process to
the /sbin/init program.
The /sbin/init program loads all services and userspace tools, and mounts all partitions listed in
/etc/fstab.
The user is presented with a login prompt for the
freshly booted Linux system.
Operating Systems Lab - UT ECE Dept
Fall 2005
9/40
The Booting Procedure (in detail)
BIOS



On Boot, Processor looks at the end of system
memory for the Basic Input/Output System or BIOS
program and runs it.
The BIOS controls the first step of the boot
process.
BIOS provides the lowest level interface to
peripheral devices.

Tests the system, looks for and checks peripherals,
and then locates a valid device with which to boot the
system.
Operating Systems Lab - UT ECE Dept
Fall 2005
10/40
The Booting Procedure (in detail)

BIOS loads into memory whatever program is residing
in the first sector of this device, called the Master Boot
Record or MBR.



The MBR is only 512 bytes in size and contains machine
code instructions for booting the machine, called a boot
loader
BIOS also loads the partition table.
Once the BIOS finds and loads the boot loader
program into memory, it yields control of the boot
process to it.
Operating Systems Lab - UT ECE Dept
Fall 2005
11/40
The Booting Procedure (in detail)
Boot Loader


X86 Arch.

LILO

GRUB
Boot loaders are broken into 2 stages

Firsts stage just locates the second stage and loads first
part of it into memory.

Second Stage displays a graphical screen showing
different OS options to boot.

Then, places the kernel from /boot and loads initial RAM
Disk initrd<kernel-version>.img

The rest of boot process is done by kernel
Operating Systems Lab - UT ECE Dept
Fall 2005
12/40
The Booting Procedure (in detail)
The Kernel




Initializes and configures the memory and various
hardware attached to system
 I/O, storage devices, all processors
Decompresses and loads initrd which contains necessary
drivers.
Initializes virtual devices
 LVM
 Software RAID
Unmounts initrd and frees up all memory used by initrd
Operating Systems Lab - UT ECE Dept
Fall 2005
13/40
The Booting Procedure (in detail)




Then, Kernel creates a root device, mounts the
root partition read-only
NOW, it is operational, BUT there are no user
applications
To set up the user environment, kernel executes
/sbin/init program
init program


Coordinates the rest of boot process
Is the grandparent of all other processes
Operating Systems Lab - UT ECE Dept
Fall 2005
14/40
The Booting Procedure (in detail)

At the first, runs /etc/rc.d/rc.sysinit script






Sets environment path, starts swap, checks file
system and initialize terminals all things!
At the first executes /etc/rc.d/init.rd/functions
Sets up graphical interface
Starts number of minimum consoles (mingetty) that all
display login screen and sets their default font
Shows the message “Welcome to RedHat Linux …
Press I to Interactive Mode”
Mounts /proc file system, configures kernel
parameters, sets up system clock, keyboard, keymap
Operating Systems Lab - UT ECE Dept
Fall 2005
15/40
The Booting Procedure (in detail)


Initializes USB
Checks root file system





In failure runs fsck
Remount file system as read-write
Activate swap partition
Runs system wide configuration scripts in
/etc/sysconfig
Then checks run level parameter in
/etc/inittab file to start or stop appropriate
services by running /etc/rc.d/rc script
Operating Systems Lab - UT ECE Dept
Fall 2005
16/40
The Booting Procedure (in detail)

Run Levels







0 - halt (Do NOT set initdefault to this)
1 - Single user mode
2 - Multiuser, without NFS
3 - Full multiuser mode
4 - unused
5 - X11
6 - reboot (Do NOT set initdefault to this)
Operating Systems Lab - UT ECE Dept
Fall 2005
17/40
The Booting Procedure (in detail)

Related files
 /etc/inittab (id:3:initdefault)
 /etc/rc. d/init.d


Contains scripts to start and stop all services
Each /etc/rc.d/rcX.d

Contains two type of soft links





K<a number><service name> : k20nfs
S<a number><service name> : S05nfs
(Numbers keeps order of scripts execution)
The Last script which init runs is /etc/rc.d/rc.local
 This file is useful for system customization
The telinit command is used to change run-levels on-the-fly on a
running Linux system.
 telinit 5
Operating Systems Lab - UT ECE Dept
Fall 2005
18/40
The Booting Procedure (in more details)





Hardware fetch-execute cycle begins
Executing Hardware Process
Executing POST
Reading boot record and load the OS into primary memory
Run kernel to initialize the computer hardware






Setting the CPU in supervisor mode.
Branching to the main entry point in the kernel.
Kernel initializes the trap table, the interrupt handler, the
scheduler, the clock, the modules, and so on.
Kernel initializes the process manager.
The hardware process then creates the initial process.
The initial process is allocated the first entry in the kernel’s
process descriptor table. Is referred to task[0] or INIT_TASK.
Operating Systems Lab - UT ECE Dept
Fall 2005
19/40
The Booting Procedure (in more details)






The initial process then creates the first useful Linux process to
run the init program and begins to execute an idle loop. (init
process also called the idle process)
Running other init programs from /etc, /bin, /sbin, /etc/rc.
During initialization, the kernel creates one process on each
communication port that can be used to support user logins.
Each of these processes copy of the getty program.
The getty process initializes itself and then waits for a user to
begin using the port.
When the user begins to use the port, getty runs the login
program, expecting authentication Information.
If the authentication is successful, then the login process
changes the current directory to the user’s home directory and
executes the specified shell program.
Operating Systems Lab - UT ECE Dept
Fall 2005
20/40
Process and Resource
Management


Each user program run as a Process
Process Manager


Creates a collection of Virtual Machines as host
CPU (fork())
Uses hardware level timers, interrupts, protection
mechanisms, IPC, scheduling and appropriate
data structures
Operating Systems Lab - UT ECE Dept
Fall 2005
21/40
Process and Resource
Management

Process Manager

Is created as a first process (PID = 0)




Other processes are forked from this process
Runs only when a process begins supervisor
mode execution (Syscall or Interrupt)
Each process is represented by a task_struct
data structure.
The task_vector is an array of pointers to
every task_struct data structure in the
system.
Operating Systems Lab - UT ECE Dept
Fall 2005
22/40
Process and Resource
Management

Process States

Running


Waiting


The process is waiting for an event or for a resource.
Stopped


The process is either running or it is ready to run.
The process has been stopped, usually by receiving a
signal.
Zombie

This is a halted process which, for some reason, still has a
task_struct data structure in the task vector.
Operating Systems Lab - UT ECE Dept
Fall 2005
23/40
Memory Management

Memory Manager





Allocates blocks of the system’s primary memory on
request
Ensures exclusive control of a block it has been allocated
Provide a means by which cooperating processes share
blocks of memory
Automatically move information between the primary and
secondary memories
Linux uses Demand Paged Virtual Memory Model
Operating Systems Lab - UT ECE Dept
Fall 2005
24/40
Memory Management

Physical memory is divided into segments of
equal size, called pages.

Type of memory:


Physical memory
Swap memory



It is a partition in hard disk that is treated as physical
memory
It is used for storing infrequent data and also hardware
caching
Virtual memory

System defines 32-bit memory address (4 GB) virtually
Operating Systems Lab - UT ECE Dept
Fall 2005
25/40
Memory Management


Processes address a virtual address and
kernel memory manager maps it into physical
address and handles page misses
Each virtual memory is divided into 2
segments


3GB user space
1GB kernel space

Kernel segment is permanently mapped and
associated with physical address
Operating Systems Lab - UT ECE Dept
Fall 2005
26/40
Device Management

Device Management



Using Polling
Using Interrupts
With each device, a Device Driver Program is
associated which does





Setting up hardware on initialization.
Bringing the associated devices into and out of services.
Receiving data from the hardware and passing it back to
the kernel.
Sending data from the kernel to the device.
Detecting and handling device errors.
Operating Systems Lab - UT ECE Dept
Fall 2005
27/40
Device Management

Each device treated as a file


In Linux everything is abstracted by file (except
CPU and Memory)
Linux are divided to

Character Devices


Are read and written on character at a time (byte
stream) like: Mouse, Keyboard
Block Devices

Are accessed by blocks of data (i.e. 1 kilo byte at a
time) like: disks
Operating Systems Lab - UT ECE Dept
Fall 2005
28/40
Device Management

Devices and Device Drivers are referenced
by two numbers

Major Number:


Defines the class of device. SCSI=21
Minor Number

A Device Driver can be used with multiple devices.
Minor number is used to distinguish among the
physical devices that use a particular device driver
Operating Systems Lab - UT ECE Dept
Fall 2005
29/40
File Management

It is responsible for




storing and retrieving information on disk
Provide a single internal view of file
File is named byte stream that can be stored
in a secondary storage as a set of blocks
Linux file manager defines common set of
functions specified by POSIX

open(), read(), lseek(), write(), close(), ioctl()
Operating Systems Lab - UT ECE Dept
Fall 2005
30/40
File Management

File Manager is built on an abstract file model
Virtual File System (VFS)

VFS does common, system-independent tasks



Checking access permission
When data to be read or written
File System Designers provide extensions to VFS
to implement system-dependent portions
Operating Systems Lab - UT ECE Dept
Fall 2005
31/40
File Management

The Unix system has the following types of
files:

Ordinary Files


Directory Files


Manage the cataloging of the file system
Special Files (devices)


Contain information entered into them by a user, an
application or …
Used to access the peripheral devices
FIFO Files for Pipes
Operating Systems Lab - UT ECE Dept
Fall 2005
32/40
File Management


Each file has an inode structure that is
identified by an i-number.
The inode contains the information required
to access the file (File Descriptor).


Access rights, owner, group, size, creation time,
…
It doesn’t contain file name
Operating Systems Lab - UT ECE Dept
Fall 2005
33/40
An Overview of the Linux
Filesystem



An operating system's le system structure is its most
basic level of organization.
Almost all of the ways an operating system interacts
with its users, applications, and security model are
dependent upon the way it stores its les on a
storage device.
A file system can be seen in terms of two different
logical categories of les:


Shareable vs. unsharable les
Variable vs. static files
Operating Systems Lab - UT ECE Dept
Fall 2005
34/40
An Overview of the Linux
Filesystem

Filesystem Hierarchy Standard (FHS), a
collaborative document that denes the names and
locations of many les and directories.

/dev/ Directory


The /dev/ directory contains le system entries which
represent devices that are attached to the system.
/etc/ Directory

The /etc/ directory is reserved for conguration les that are
local to the machine. No binaries are to be put in /etc/.
Operating Systems Lab - UT ECE Dept
Fall 2005
35/40
An Overview of the Linux
Filesystem

The /lib/ Directory



The /lib/ directory should contain only those
libraries that are needed to execute the binaries in
/bin/ and /sbin/.
These shared library images are particularly
important for booting the system and executing
commands within the root le system.
/mnt/ Directory

The /mnt/ directory is for temporarily mounted le
systems, such as CD-ROMs and oppy disks.
Operating Systems Lab - UT ECE Dept
Fall 2005
36/40
An Overview of the Linux
Filesystem

/opt/ Directory


The /opt/ directory provides storage for large,
static application software packages.
A package placing files in the /opt/ directory
creates a directory bearing the same name as the
package. This directory in turn holds les that
otherwise would be scattered throughout the file
system, giving the system administrator an easy
way to determine the role of each file within a
particular package.
Operating Systems Lab - UT ECE Dept
Fall 2005
37/40
An Overview of the Linux
Filesystem

/proc/ Directory


The /proc/ directory contains special files that
either extract information from or send
information to the kernel.
/sbin/ Directory


The /sbin/ directory is for executables used only
by the root user.
The executables in /sbin/ are only used to boot
and mount /usr/ and perform system recovery
operations.
Operating Systems Lab - UT ECE Dept
Fall 2005
38/40
An Overview of the Linux
Filesystem

/usr/ Directory


The /usr/ directory is for les that can be shared
across a whole site. The /usr/ directory usually
has its own partition, and it should be
mountable read-only.
/usr/local/ Directory



The /usr/local hierarchy is for use by the system
administrator when installing software locally.
It may be used for programs and data that are shareable
among a group of hosts, but not found in /usr.“
is similar in structure to the /usr/ directory.
Operating Systems Lab - UT ECE Dept
Fall 2005
39/40
An Overview of the Linux
Filesystem

/var/ Directory

Since the FHS requires Linux to mount /usr/ readonly, any programs that write log les or need
spool/ or lock/ directories should write them to the
/var/ directory.
Operating Systems Lab - UT ECE Dept
Fall 2005
40/40