Docstoc

OS1

Document Sample
OS1 Powered By Docstoc
					Operating Systems Lab.
                                 (#1)



 University of Tehran – ECE Dept.
               Fall 2005


            Reza Shokri
           shokri@ece.ut.ac.ir
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   2/40
                                Fall 2005
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        3/40
                                      Fall 2005
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   4/40
                                Fall 2005
Kernel Organization




          Operating Systems Lab - UT ECE Dept   5/40
                        Fall 2005
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             6/40
                                        Fall 2005
Linux Versions




          Operating Systems Lab - UT ECE Dept   7/40
                        Fall 2005
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   8/40
                                 Fall 2005
The Booting Procedure
   The kernel transfers control of the boot process to
    the /sbin/init program.
   The /sbin/init program loads all services and user-
    space 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   9/40
                                  Fall 2005
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    10/40
                                   Fall 2005
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            11/40
                                     Fall 2005
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         12/40
                                     Fall 2005
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   13/40
                                   Fall 2005
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   14/40
                                   Fall 2005
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   15/40
                                    Fall 2005
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   16/40
                                        Fall 2005
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   17/40
                                    Fall 2005
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   18/40
                                             Fall 2005
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           19/40
                                        Fall 2005
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            20/40
                                     Fall 2005
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   21/40
                                   Fall 2005
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   22/40
                                      Fall 2005
Process and Resource
Management
   Process States
       Running
            The process is either running or it is ready to run.
       Waiting
            The process is waiting for an event or for a resource.
       Stopped
            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          23/40
                                        Fall 2005
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      24/40
                                      Fall 2005
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             25/40
                                           Fall 2005
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   26/40
                                     Fall 2005
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   27/40
                                         Fall 2005
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        28/40
                                       Fall 2005
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       29/40
                                       Fall 2005
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   30/40
                                     Fall 2005
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   31/40
                                       Fall 2005
File Management
   The Unix system has the following types of
    files:
       Ordinary Files
           Contain information entered into them by a user, an
            application or …
       Directory Files
           Manage the cataloging of the file system
       Special Files (devices)
           Used to access the peripheral devices
       FIFO Files for Pipes

                         Operating Systems Lab - UT ECE Dept      32/40
                                       Fall 2005
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   33/40
                                    Fall 2005
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   34/40
                                     Fall 2005
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       35/40
                                      Fall 2005
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   36/40
                                    Fall 2005
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   37/40
                                   Fall 2005
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   38/40
                                    Fall 2005
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    39/40
                                     Fall 2005
An Overview of the Linux
Filesystem
   /var/ Directory
       Since the FHS requires Linux to mount /usr/ read-
        only, 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   40/40
                                    Fall 2005

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:10/16/2011
language:English
pages:40