1. Operating Systems Lab. (#1) University of Tehran – ECE Dept. Fall 2005 Reza Shokri shokri@ece.ut.ac.ir

2. Operating Systems Lab - UT ECE Dept Fall 2005 2/40 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

3. Operating Systems Lab - UT ECE Dept Fall 2005 3/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

4. Operating Systems Lab - UT ECE Dept Fall 2005 4/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

5. Operating Systems Lab - UT ECE Dept Fall 2005 5/40 Kernel Organization

6. Operating Systems Lab - UT ECE Dept Fall 2005 6/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.

7. Operating Systems Lab - UT ECE Dept Fall 2005 7/40 Linux Versions

8. Operating Systems Lab - UT ECE Dept Fall 2005 8/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.

9. Operating Systems Lab - UT ECE Dept Fall 2005 9/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 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.

10. Operating Systems Lab - UT ECE Dept Fall 2005 10/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.

11. Operating Systems Lab - UT ECE Dept Fall 2005 11/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.

12. Operating Systems Lab - UT ECE Dept Fall 2005 12/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.img The rest of boot process is done by kernel

13. Operating Systems Lab - UT ECE Dept Fall 2005 13/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

14. Operating Systems Lab - UT ECE Dept Fall 2005 14/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

15. Operating Systems Lab - UT ECE Dept Fall 2005 15/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

16. Operating Systems Lab - UT ECE Dept Fall 2005 16/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

17. Operating Systems Lab - UT ECE Dept Fall 2005 17/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)

18. Operating Systems Lab - UT ECE Dept Fall 2005 18/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 : k20nfs  S : 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

19. Operating Systems Lab - UT ECE Dept Fall 2005 19/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.

20. Operating Systems Lab - UT ECE Dept Fall 2005 20/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.

21. Operating Systems Lab - UT ECE Dept Fall 2005 21/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

22. Operating Systems Lab - UT ECE Dept Fall 2005 22/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.

23. Operating Systems Lab - UT ECE Dept Fall 2005 23/40 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.

24. Operating Systems Lab - UT ECE Dept Fall 2005 24/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

25. Operating Systems Lab - UT ECE Dept Fall 2005 25/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

26. Operating Systems Lab - UT ECE Dept Fall 2005 26/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

27. Operating Systems Lab - UT ECE Dept Fall 2005 27/40 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.

28. Operating Systems Lab - UT ECE Dept Fall 2005 28/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

29. Operating Systems Lab - UT ECE Dept Fall 2005 29/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

30. Operating Systems Lab - UT ECE Dept Fall 2005 30/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()

31. Operating Systems Lab - UT ECE Dept Fall 2005 31/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

32. Operating Systems Lab - UT ECE Dept Fall 2005 32/40 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

33. Operating Systems Lab - UT ECE Dept Fall 2005 33/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

34. Operating Systems Lab - UT ECE Dept Fall 2005 34/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

35. Operating Systems Lab - UT ECE Dept Fall 2005 35/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/.

36. Operating Systems Lab - UT ECE Dept Fall 2005 36/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.

37. Operating Systems Lab - UT ECE Dept Fall 2005 37/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.

38. Operating Systems Lab - UT ECE Dept Fall 2005 38/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.

39. Operating Systems Lab - UT ECE Dept Fall 2005 39/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.

40. Operating Systems Lab - UT ECE Dept Fall 2005 40/40 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.