Operating systems : internals and design principles / William Stallings. Operating
systems ... Operating systems : a modern perspective / Gary J. Nutt. Operating ...
1 Introduction Name: Paul Rothwell. Office: B223L Phone: 021-4335524 Email:
[email protected]
1.1 Books Library section: 005.43 Operating systems : internals and design principles / William Stallings. Operating systems / Harvey M. Deitel, Paul J. Deitel and David R. Choffnes. Operating systems / Colin Ritchie. Operating system concepts / Abraham Silberschatz and Peter Baer Galvin. Applied operating system concepts / Avi Silberschatz, Peter Galvin and Greg Gagne. Modern operating systems / Andrew S. Tanenbaum. Operating systems : design and implementation / Andrew S. Tanenbaum, Alfred Woodhull. Operating systems : a modern perspective / Gary J. Nutt. Operating systems : a systematic view / William S. Davis, T.M. Rajkumar.
1.2 Course summary Section 1: Introduction • Course summary • What is an Operating System (OS)? • Historical overview • System Overview • Brief history of Windows and Unix Section 2: Overview of system services • Introduction • Interrupts Section 3: Process Management • Processes • Scheduling Section 4: Memory Management • Basic Memory Management schemes • Paging Section 5: I/O, Files and Devices • I/O management • Disk scheduling • Disk space management • Files and File systems • Storage media Practical Lab work: Linux Shell programming
1.3 What is an Operating System (OS)? 1.3.1 Definition An OS is a suite of programs which together provide an interface between the user and the hardware. That is, the OS manages the complex interactions required by a running program when dealing with processor(s) (CPU), main memory (RAM), secondary storage (disks, memory sticks), printers, keyboards, screens (display and touch), network cards, wireless adapters, etc. Not only that but it presents the user/application programmer with a simplified (but effective) view of these complex interactions. The OS also manages the allocation of machine resources to running programs. It must manage this allocation fairly and efficiently. Can divide computer system into 4 parts: 1. Users 2. Application programs 3. Operating System (i.e. Systems Software) 4. Hardware Users Application Programs Operating System Hardware
Utilities Systems Programs Machine Language MicroArchitecture Physical devices
Web browser Word processor Compilers/Editors CPU scheduler Instruction Set ALU, CU Chips, Disks
1.3.2 Goals of an OS 1. Make the computer convenient to use; 2. Manage the use of hardware resources efficiently & fairly. 3. Allow easy expansion (requires modular design). Historically goal 2 was more important. So the development of OS has been fuelled by performance considerations. More recently (last 30 years) goals 1 & 3 are more important.
1.3.3 Roles of OS • Provides a workable interface for use. • Co-ordinates the use of the hardware by the programs. • Allocates resources of the system to the programs. E.g. CPU time, main memory space, disk space, i/o devices, etc. OS must manage conflicts fairly and efficiently. • Controls access to and use of the system; security from damage; protection of processes. • Operates and controls use of I/O devices.
1.4 Historical overview Contemporary OS is a product of its historical development driven by technological advances and user demands.
1.4.1 In the beginning... Early systems had no OS. The programmer: • entered the program in binary at the front panel switches; • ran it and monitored its execution; • debugged it by examining memory and register contents directly. 1.4.1.1 Problems: 1. Scheduling - wasted time 2. Setup time - disproportionate to run time 3. Error prone - vacuum tubes blowing
1.4.2 And then... With time additional hardware (h/w) and software (s/w) were developed to ease the burden: 1.4.2.1 h/w: New i/o devices (line printers, tape, punched card, etc.) But now CPU wasted time waiting for i/o. [see later] 1.4.2.2 s/w: Loaders, assemblers, linkers, debuggers; Libraries of common functions. Software for running each device i.e. device drivers. Compilers for high level languages developed. These extras made the operation of the machine easier for the programmer but made the setup of jobs more complex and lengthy. Thus professional operators were invented and later, to help them, simple Op. Sys’s were developed.
1.4.3 So there came to pass... These simple OS were called Monitors. The monitor remained resident and running in RAM. The operator gathered similar programs together into batches. Thus the machine did ‘batch processing’. The monitor: 1. automatically sequenced the jobs; 2. interpreted control instructions (e.g. call compiler, load program, link program, run program, etc.); 3. contained device drivers and interrupt handlers; 4. protected its own memory from user programs; 5. timed jobs; 6. had privileged instructions e.g. i/o instructions: “no user program could come to an i/o device except through the monitor”.
1.5 System Overview 1.5.1 Basic Components The system consists of CPU, Main Memory, I/O Module, and System Bus.
The CPU consists of registers, ALU, control unit and internal connections (address, data and control buses).
1.5.1.1 Processor (CPU) Consists of: • ALU – Arithmetic Logic Unit which performs operations (add, sub, etc.); • CU – Control Unit which co-ordinates operation of the various CPU components; • Programmer-visible Registers – used by assembly language programmers. • Control and Status registers which contain information used to control the operation of the processor. These include: IR – Instruction Register which contains the instruction last fetched; PC – Program Counter which contains the memory address of the next instruction to be fetched; MAR – Memory Address Register which contains the address for the next read/write; MBR – Memory Buffer Register which contains the data to be written/read to/from memory; I/OAR – I/O Address Register which specifies an i/o device;
I/OBR – I/O Buffer Register which is used for exchange of data to/from the i/o module;
1.5.1.2 Main Memory and I/O Module Main memory is the RAM (Random Access Memory) and the I/O module is responsible for dealing with all input and output operations. [Much more on these later.] 1.5.1.3 Address, data and control buses • Used for transfer of information between the components. • Address bus carries addresses from a requesting component to the memory. • Data bus carries data to/from components. • Control bus specifies which component should take or get what from which bus. e.g. instruction requires some data from memory – control bus signals what’s happening, memory address is sent along the address bus, data is placed on data bus, control unit signals to register A (which has been listening) to pick the data off the data bus.
1.5.2 Instruction Fetch and Execute At the heart of each CPU there is a basic blind rhythm called the ‘fetch-execute cycle.’ The instruction held at the location specified by the PC is fetched (collected from memory), the PC is incremented to point to the next instruction, the fetched instruction is executed, and this repeats: another fetch, another execute, etc. Note that the PC is incremented to the address of the next word in memory (i.e. the next instruction normally). But what if the next instruction is stored somewhere else? Or the next instruction should be the first of an entirely different program? Or the last instruction did something fatal? Or there’s some input ready to be picked up from the data bus? Or this program’s time slot on the CPU is up? Or there’s a power failure and the system has 3 seconds to try and save everything?
1.5.3 Interrupts Dealing with all of these exceptions and all of the switching from i/o to processing requires interrupts. Take i/o: When an i/o operation was finished (e.g. reading in a record) the i/o device would interrupt the CPU. The CPU would respond by jumping to a special program called an interrupt service routine. Typically this routine would check if, say, the input buffer was full and if not would begin another input operation. Control would then revert to whatever the CPU was doing when interrupted. Take error handling: If an error occurs the CPU can’t simply go on to the next instruction – it must first deal with the problem. If an error occurs an error interrupt would occur and direct the CPU’s attention to an error handling routine. Again when the problem is dealt with the CPU could revert to its interrupted work (depending on the type of error). Interrupt response time was crucial to the smooth running of the computer. Faster devices (e.g. disks) tended to generate more interrupts per second. To avoid the CPU having to service interrupts to the detriment of its other work, such devices were given direct memory access (DMA). Thus they could transfer a large amount of data without the CPU intervening. Interrupts were only generated for each block of data being transferred (rather than for each byte).
1.5.4 Multiprogramming/Multitasking Multiprogramming or Multitasking refer to the task of running several programs at the same time. For example, a payroll program, a printing task, a statistics program, all doing their separate work. It is up to the OS to divide its time between the jobs. From the point of view of each running program it should seem that they have the system to themselves. With interrupt handling tools the OS was capable of dealing with more than one program running at the same time. For example, while one job is waiting for input, another could be running some computation, while yet another could be waiting for an output device, and so on. All of these programs are said to be running concurrently. The job scheduling task of the OS was to juggle the CPU time so that each job got access to it in some fair and efficient manner. This task is referred to as CPU Scheduling. CPU scheduling depends on being able to interrupt one program and resume another. Also when several jobs are ready to run on the CPU they must all be stored in main memory. Thus in a multitasking system there must be some way of managing the main memory so that each program gets the space it needs and doesn’t interfere with the others. This management task is known as Memory Management. Because multitasking is allowed then the OS must cope with concurrency issues. Programs running concurrently could be half way through printing a document or writing data to a database when interrupted – they must be guaranteed that no other program will interfere with the work they are doing
by printing on the same paper or reading half-baked data from the database. These issues are concurrency issues.
1.5.5 Kernel and System calls The kernel is the core of the OS. Kernel software has exclusive access to system data and h/w. Remaining software running in user mode has limited direct access to system data and no direct access to h/w. The Kernel consists of the most fundamental components of the OS. One part manages scheduling, context switching, memory management, inter-process communication and multiprocessor synchronisation (if any). The other part deals with the file system management and interrupts (i/o, etc.). All application and utility programs access the fundamental OS operations through OS system calls. These system calls are the only way to access the h/w; that is, they provide the interface between the programs and the OS. For example, if writing a program to output ‘Hello World’ to the screen the program will contain some instruction like: system.out(‘Hello World’); This call is translated by the compiler/assembler into code which will call the OS giving it information about the data to be output, and the output device. That is something like: system_i/o_display(data_address, no_of_bytes, screen_device_identifier); In other words a system call to the OS will ask the kernel to take a certain number of bytes from RAM starting at data_address and have them displayed on a particular device (the screen). The kernel will arrange to call the correct device driver software to communicate with the screen.
1.5.6 Command Interpreter All operating systems must have some way of understanding and carrying out instructions from users. This is achieved through a command interpretation program which runs continuously when you log in (for example). The user types a command or clicks an icon, the interpreter translates the user command/action into something meaningful (or complains if it cannot) and then calls up the necessary system programs, utilities, or applications that will carry out the work. The interpreter is less obvious in a GUI environment (e.g. Windows) and more so in a command based environment (e.g. a Linux command terminal). These interpreters usually understand more than simple commands. They can interpret and carry out ‘command programs’. That is, you can write programs (with if’s and while’s etc.) which instruct the system carry out a complex series of tasks. In UNIX type systems the command interpreter is called the ‘shell’ and we will be doing some programming with a Linux shell.
1.6 History of Example Systems 1.6.1 Windows family MS-DOS is a distant ancestor. DOS 1.0 released 1981. (8086 processor; floppy disks; single level directory) DOS 2.0 released 1983. (fixed hard disks; hierarchical directories; internal commands; i/o redirection; background printing) DOS 3.0 & 3.1 (1984) (80286 processor; new keyboard and hard disk peripherals; network support) DOS 3.3 (1987) (80386) -> DOS 6.2 (1993) Windows 3.0 (1990) (Graphical User Interface) Windows NT (New Technology – not based on DOS) (v3.1 1993, v3.5 1994 – look like windows 3.1) Windows 95 (1995 – incorporates DOS) Windows NT (v4.0 1996 looks like Windows 95) Windows 98 (1998 – incorporates DOS) Windows 2000 (2000 – replaces DOS-based Windows 95, 98 and Windows NT 4.0) Windows XP (2001) Windows Vista (2007) Windows 7 (2009) Windows 8 (Oct 2012) Windows 10 (Sept. 2014)
1.6.2 UNIX/Linux • Unix was written in Bell Labs in assembly language in 1970 running on a PDP-7. • Re-written in C in 1973 and ported to a PDP-11. • Published in 1974 and distributed free to universities and some commercial organisations. • Slowly evolved through additions from many sources. • Commercially sold in 1982 as UNIX System III. Notable strains of UNIX are: Xenix, System V (release 4), and BSD (Berkeley Standard Definition). UNIX System V Release 4 (SVR4: 1989) represented a standardisation across the many strains. Linux (based on SVR4) developed independently for PCs (1991) by Linus Torvalds under FSFs GNU Public License (GPL). Linux comes in many forms: Ubuntu, SUSE, etc.
1.6.3 Mobile OS Various mobile OS for smartphones released since 2000 notably iOS & Android.
