IT and Computer 1st edition by Andrew Tanenbaum

download

https://ebookball.com/product/it-and-computer-1st-edition-by-
andrew-tanenbaum-25064/

Instantly Access and Download Textbook at https://ebookball.com

 Get Your Digital Files Instantly: PDF, ePub, MOBI and More
Quick Digital Downloads: PDF, ePub, MOBI and Other Formats

Computer Networks 4th Edition by Andrew Tanenbaum ISBN 0130661023

9780130661029

https://ebookball.com/product/computer-networks-4th-edition-by-
andrew-tanenbaum-isbn-0130661023-9780130661029-25006/

Computer Networks 5th Edition by Andrew S Tanenbaum ISBN 0133072622

9780133072624

https://ebookball.com/product/computer-networks-5th-edition-by-
andrew-s-tanenbaum-isbn-0133072622-9780133072624-15920/

Structured Computer Organization 5th edition by Andrew Tanenbaum ISBN

0131485210 978-0131485211

https://ebookball.com/product/structured-computer-
organization-5th-edition-by-andrew-tanenbaum-
isbn-0131485210-978-0131485211-16386/

Structured Computer Organization 5th Edition by Andrew S Tanenbaum

ISBN 0131485210 9780131485211

https://ebookball.com/product/structured-computer-
organization-5th-edition-by-andrew-s-tanenbaum-
isbn-0131485210-9780131485211-16612/
Computer Networks 5th edition by Andrew Tanenbaum, David Wetherall
ISBN ‎ 0132126958 978-0132126953

https://ebookball.com/product/computer-networks-5th-edition-by-
andrew-tanenbaum-david-wetherall-isbn-
aeurz-0132126958-978-0132126953-16362/

Operating Systems Design and Implementation 3rd Edition by Andrew

Tanenbaum, Albert Woodhull 0131429388 9780131429383

https://ebookball.com/product/operating-systems-design-and-
implementation-3rd-edition-by-andrew-tanenbaum-albert-
woodhull-0131429388-9780131429383-17132/

Operating System Design and Implementation 2nd Edition by Andrew

Tanenbaum, Albert Woodhull ISBN 0136386776 9780136386773

https://ebookball.com/product/operating-system-design-and-
implementation-2nd-edition-by-andrew-tanenbaum-albert-woodhull-
isbn-0136386776-9780136386773-25066/

IT and Computer CCXLVI 1st Edition by Pankaj Jalote

https://ebookball.com/product/it-and-computer-ccxlvi-1st-edition-
by-pankaj-jalote-15656/

IT and Computer CCXLVI 1st Edition by Pankaj Jalote

https://ebookball.com/product/it-and-computer-ccxlvi-1st-edition-
by-pankaj-jalote-15600/
PREFACE The world has changed a great deal since the first edition
of this book ap- appeared in 1992. Computer networks and
distributed systems of all kinds have become very common. Small
children now roam the Internet, where previously only computer
professionals went. As a consequence, this book has changed a
great deal, too. The most obvious change is that the first edition was
about half on single- processor operating systems and half on
distributed sysiems. 1 chose that format in 1991 because few
universities then had courses on distributed systems and whatever
students learned about distributed systems had to be put into the
operat- operating sysiems course, for which this book was intended.
Now most universities have a separate course on distributed
systems, so it is not necessary to try to com- combine the two
subjects into one course and one book. This book is intended for a
first course on operating systems, and as such focuses mostly on
traditional single-processor systems. 1 have coauthored two other
books on operating systems. This leads lo two possible course
sequences. Practically-oriented sequence; 1. Operating Systems
Design and Implementation by Tanenbaum and Woodhull 2.
Distributed Systems by Tanenbaum and Van Steen Traditional
sequence: 1. Modern Operating Systems by Tanenbaum 2.
Distributed Systems by Tanenbaum and Van Steen

XXIV PREFACE The former sequence uses M1N1X and the students
are expected to experiment with MINIX in an accompanying
laboratory supplementing the first course. The latter sequence'does
not use M1N1X. Instead, some small simulators are available that
can be used for student exercises during a first course using this
book. These simulators can be found starting on the author's Web
page: www.cs.vu.nl/-ast/by clicking on Software and supplementary
material for my books . In addition to the major change of switching
the emphasis to single-processor operating systems in this book,
other major changes include the addition of entire chapters on
computer security, multimedia operating systems, and Windows
2000, all important and timely topics. In addition, a new and unique
chapter on operat- operating system design has been added.
Another new feature is that many chapters now have a section on
research about the topic of the chapter. This is intended to introduce
the reader lo modern work in processes, memory management, and
so on. These sections have numerous references to the current
research literature for the interested reader. In addition, Chapter 13
has many introductory and tutorial references. Finally, numerous
topics have been added to this book or heavily revised. These topics
include: graphical user intefaces, multiprocessor operating systems,
power management for laptops, trusted systems, viruses, network
terminals, CD- ROM file systems, mutexes, RAID, soft timers, stable
storage, fair-share schedul- scheduling, and new paging algorithms-
Many new problems have been added and old ones updated. The
total number of problems now exceeds 450. A solutions manual is
available to professors using this book in a course. They can obtain a
copy from their local Prentice Hall representative. In addition, over
250 new references to the current literature have been added to
bring the book up to date Despite the removal of more than 400
pages of old material, the book has increased in size due to the large
amount of new material added. While the book is still suitable for a
one-semester or two-quarter course, it is probably too long for a
one-quarter or one-trimester course at most universities. For this
reason, the book has been designed in a modular way. Any course
on operating system should cover chapters ! through 6. This is basic
material that every student show know. If additional time is
available, additional chapters can be covered. Each ot them assumes
the reader has finished chapters 1 through 6, but Chaps. 7 through
12 are each self contained, .so any desired subset can be used and
in any order, depending on the interests of the instructor In the
author's opinion, Chaps 7 through 12 are much more interesting
than the earlier ones. Instructors should tell their students that they
have to eat their broccoli before they can have the douhle chocolate
fudge cake dessert I would like to thank the following people for
their help in reviewing parts of the manuscript: Rida Bazzi, Riccardo
Bettati, Felipe Cabrera, Richard Chapman John Connely, John
Dickinson, John Elliott, Deborah Frincke, Chandana Gamage, Robbert
Geist, David Golds, Jim Griffioen, Gary Harkin, Frans Kaashoek, Muk-

PREFACE XXV kai Krishnamoorthy, Monica Lam, Jussi Leiwo, Herb

Mayer. Kirk McKusick, Evi Nemeth, Bill Potvin, Prasant Shenoy,
Thomas, Skinner, Xian-He Sun, William Terry, Robbert Van Renege,
and Maarten van Steen. Jamie Hanrahan, Mark Russinovich, and
Dave Solomon were enormou.sly knowledgeable about Win-
Windows 2000 and very helpful. Special thanks go to Al Woodhull for
valuable reviews and thinking of many new end-of-chapter problems
My students were also helpful wilh comments and feedback,
especially Staas de Jong, Jan de Vos, Niels Drost, David Fokkema,
Auke f-olkerts, Peter Groene- wegen, Wilto lbes, Stefan Jansen,
Jeroen Ketema, Joen Mulder, Irwin Oppenheim, Stef Post. Umar
Rehman, Daniel Rijkhof, Maarten Sander, Maunts van der Schee, Rik
van der Stoel, Mark van Dnet, Dennis van Veen, and Thomas
Barbara and Marvin are still wonderful, as usual, each in a unique
way Finally, last but not least, 1 would like to thank Suzanne for her
love and patience, not to mention alt the druiven and kersen, which
have replaced ihe sinasappelsap Andrew S. Tanenbaum

CONTENTS PREFACE 1 INTRODUCTION 1.1. WHAT IS AN

OPERATING SYSTEM1' 3 1.1.1. The Operating Sysiem as an
Extended Mach 1.1.2. The Operaiing Sysiem a.s a Resource Manag.
1.2. HISTORY OF OPERATING SYSTEMS 6 1.2.1. The First
Genera.ion A945-55) 6 1.2.2. The Second Generation A955-65) 7
1.2.3. The Third Generation A965-1980) 9 1.2.4. The Fourth
Generaiion A980-Present) 13 1.2.5. Ontogeny Recapitulates
Phylogeny 16 1.3. THE OPERATING SYSTEM ZOO 18 1.3.1.
Mainframe Operating Systems 18 t .3.2. Server Operating Systems
19 1.3.3. Multiprocessor Operating Systems 19 1.3.4. Personal
Computer Operating Sysiems 19 1.3.5. Real-Time Operating Systems
19 1.3.6. Embedded Operating Sysiems 20 1.3.7. Sman Card
Operating Sysiems 20
CONTENTS COMPUTER HARDWARE REVIEW 20 1.4.1. Processors 21
1.4.2. Memory 23 1.4.3. I/O Devices 28 I 4.4. Buses 3t OPERATING
SYSTEM CONCEPTS 34 1.5.1. Processes 34 1.5 2. Deadlocks 36 1.5
3. Memory Managemeni 37 1.5.4. Input/Ouiput 38 1.5.5. Files 38
1.5.6. Security 41 1.5.7. The Shell 41 1.5.8. Recycling of Concepts 43
SYSTEM CALLS 44 1.6.1. Sysiem Calls for Process Managemeni 4g t
.6.2. System Calls for File Management 50 1.6.3. System Calls for
Directory Management 51 1.6.4. Miscellaneous System Calls 53
1.6.5. The Windows Win32 API 53 1.7. OPERATING SYSTEM
STRUCTURE 56 1.7.1. Monoliihic Systems 56 1.7.2. Layered Systems
57 1.7.3. Virtual Machines 59 1.7.4. Exokernets 61 1.7.5. Client-
Server Model 61 1.8. RESEARCH ON OPERATING SYSTEMS 63 1.9.
OUTLINE OF THE REST OF THIS BOOK 65 1.10. METRIC UNITS 66
1.11. SUMMARY 67

CONTENTS 'X 2 PROCESSES AND THREADS 71 2.1. PROCESSES 71

2.1.1. The Process Model 72 2.1.2. Process Creation 73 2.1.3-
Process Termination 75 2.1.4 Process Hierarchies 76 2 1 5 Process
Stales 77 2.1.6- Implementation of Processes 79 2.2 THREADS 81
2.2.1. The Thread Model 81 2.2.2. Thread Usage 85 2-2.3.
Implementing Threads in User Space 90 2-2.4. Implementing
Threads in the Kernel 93 2-2.5. Hybrid Implementations 94 2.2.6.
Scheduler Activations 94 2.2.7. Pop-lip Threads 96 2.2.8. Making
Single-Threaded Code Multithreaded 97 2.3. INTERPROCESS
COMMUNICATION 100 2.3.1. Race Conditions 100 2.3.2- Critical
Regions 102 2.3.3. Mutual Exclusion wiih Busy Waning 103 2.3.4.
Sleep and Wakeup 108 '2.3.5. Semaphores 110 2.3.6. Mutexts 113
2.3.7. Monitors 115 2.3.8. Message Passing 119 2.3.9. Barriers 123
2.4. CLASSICAL 1PC PROBLEMS 124 2.4.1. The Dining Philosophers
Problem 125 2.4.2. The Readers and Wri.ers Problem 128 2.4.3. The
Sleeping Barber Problem 129 2.5. SCHEDULING 132 2.5.1.
Introduction to Scheduling 132 2.5.2. Scheduling in Batch Systems
138 2.5 3. Scheduling in Inieraciive Systems 142 2.5.4. Scheduling in
Real-Time Systems 148 2.5.5. Policy versus Mechanism 149 2.5.6.
Thread Scheduling 150
x CONTENTS 2.6. RESEARCH ON PROCESSES AND THREADS 151
2.7. SUMMARY 152 3 DEADLOCKS 159 3.1- RESOURCES 160 3.1.1.
Preemptable andNonpreempiable Resources 160 3.1.2. Resource
Acquisition 161 3.2. INTRODUCTION TO DEADLOCKS 163 3.2.1.
Conditions for Deadlock 164 3.2.2. Deadlock Modeling 164 3.3. THE
OSTRICH ALGORITHM 167 3.4. DEADLOCK DETECTION AND
RECOVERY 168 3.4.1. Deadlock Detecnon with One Resource ot
Each Type 168 3.4.2. Deadlock Deiecnon with Multiple Resource of
Each Type 171 3.4.3. Recovery from Deadlock 173 3.5. DEADLOCK
AVOIDANCE 175 3.5.!. Resource Trajectories 175 3.5.2. Safe and
Unsafe Stales 176 3.5.3. The Banker's Algorithm for a Single
Resource 178 3.5.4. The Banker's Algorithm for Multiple Resources
179 3.6. DEADLOCK PREVENTION 180 3.6.1. Attacking (he Mutual
Exclusion Condition 180 3.6.2. Attacking the Hold and Wait Condition
181 3.6.3. Attacking the No Preemption Condition 182 3.6.4.
Attacking the Circular Wait Condition 182 3.7. OTHER ISSUES 183
3.7.1. Two-Phase Locking 183 3.7.2. Nonresource Deadlocks 184
3.7.3. Starvation 184 3.8. RESEARCH ON DEADLOCKS 185 3.9.
SUMMARY 185

CONTENTS XI 4 MEMORY MANAGEMENT 189 4 I BASIC MEMORY

MANAGEMENT 190 4.1. ] Monoprogramming without Swapping or
Paging 190 4.1.2. Multiprogramming with Fixed Partitions !9I 4.1.3.
Modeling Multiprogramming 192 4.1.4 Analysis of Multiprogramming
System Performance 194 4.1.5. Relocation and Protection 194 4.2.
SWAPPING !96 4.2.1. Memory Management with Bitmaps 199 4.2.2.
Memory Management with Linked Lists 200 4.3. VIRTUAL MEMORY
202 4.3.1. Paging 202 4.3.2. Page Tables 205 4.3.3. TLBs—
Translation Lookaside Buffers 211 4.3.4. inverted Page Tables 213
4.4. PAGE REPLACEMENT ALGORITHMS 214 4.4.1. The Optima!
Page Replacement Algorithm 215 4.4.2. The Not Recently Used Page
Replacement Algorithm 216 4.4.3. The First-In, First-Out 217 4.4.4.
The Second Chance Page Replacement Algorithm 2]7 4.4.5. The
Clock Page Replacement Algorithm 218 4.4.6. The Least Recently
Used 218 4.4.7. Simulating LRU in Software 220 4.4.8. The Working
Set Page Replacement Algorithm 222 4.4.9. The WSClock Page
Replacement Algorithm 225 4.4.:. Summary of Page Replacement
Algorithms 227 4.5. MODELING PAGE REPLACEMENT ALGORITHMS
228 4.5.1. Belady's Anomaly 229 4.5.2. Stack Algorithms 229 4.5.3.
The Distance String 232 4.5.4. Predicting Page Fault Rates 233 4.6.
DESIGN ISSUES FOR PAGING SYSTEMS 234 4.6.1. Local versus
Global Allocation Policies 234 4.6.2. Load Control 236 4.6.3. Page
Size 237 4.6.4. Separate Instruction and Data Spaces 239

XI] CONTENTS 4.6.5. Shared Pages 239 4.6.6. Cleaning Policy 241
4.6 7. Virtual Memory Interface 241 4 7 IMPLEMENTATION ISSUES
242 4.7.1. Operating System Involvement with Paging 242 4.7.2.
Page Fault Handling 243 4.7.3. Instruction Backup 244 4.7.4. Locking
Pages in Memory 246 4.7.5. Backing Store 246 4.7.6. Separation of
Policy and Mechanism 247 4.8. SEGMENTATION 249 4.8.1.
Implementation of Pure Segmentation 253 4.8.2. Segmentation with
Paging. MULTICS 254 4.8.3. Segmentation with Paging: The Intel
Pentium 257 4.9. RESEARCH ON MEMORY MANAGEMENT 262 4.10.
SUMMARY 262 5 INPUT/OUTPUT 269 5.1 PRINCIPLES OF I/O
HARDWARE 269 5.1.1. I/O Devices 270 5.1.2. Device Controllers 271
5.1.3. Memory-Mapped I/O 272 5.1.4. Direct Memory Access 276
5.1.5. Interrupts Revisited 279 5.2. PRiNCIPLES OF I/O SOFTWARE
282 5.2.1. Goals ot the I/O Software 283 5.2.2. Programmed I/O
284 5 2.3. lnterrupt-Dnven I/O 286 5 2.4. I/O Using DMA 287 5.3.
I/O SOFTWARE LAYERS 287 5.3.1. interrupt Handlers 287 5.3.2.
Device Drivers 289

5-3.3. Device-Independent I/O Software 292 5.3.4. User-Space I/O

Software 298 5.4. DISKS 300 5.4.1. Disk Hardware 300 5.4.2. Disk
Formatting 315 5.4.3. Disk Arm Scheduling Algorithms 318 5.4.4.
Error Handling 322 5.4.5. Stable Storage 324 5.5. CLOCKS 327 5.5-1
Clock Hardware 328 5.5.2. Clock Software 329 5.5.3. Soft Timers
332 5.6. CHARACTER-ORIENTED TERMINALS 333 5.6.1. RS-232
Terminal Hardware 334 5.6.2. Input Software 336 5.6.3. Output
Software 34! 5.7. GRAPHICAL USER INTERFACRS 342 5.7.1.
Persona! Computer Keyboard, Mouse, and Display Hardware 343
5.7.2. Input Software 347 5.7.3. Output Software for Windows 347
5.8. NETWORK TERMINALS 355 5.8.1. The X Window System 356
5.8.2. The SUM Network Terminal 360 5.9. POWER MANAGEMENT
363 5.9.1. Hardware Issues 364 5.9.2. Operating System Issues 365
5.9.3. Degraded Operation 370 5.10. RESEARCH ON INPUT/OUTPUT
371 5.11. SUMMARY 372

XIV 6 FILE SYSTEMS 379 FILES 380 .1. FilcNai ing 380 ;ture 382 .3.
File Types 383 .4. File Access 385 5. File Attributes, 386 .6. File
Operations 387 .7. An Example Program Using File System Calls,
6.1.8. Memory-Mapped Files 391 6.2- DIRECTORIES 393 6.2.1-
Single-Level Directory Systems 393 6.2.2. Two-level Directory
Systems 394 6.2.3. Hierarchical Directory Systems 395 6.2.4. Path
Names 395 6.2.5. Directory Operations, 398 6.3. FILE SYSTEM
IMPLEMENTATION 399 6.3.1. File System Layout 399 6.3.2.
Implementing Files 400 6.3.3. Implementing Directorie.s 405 6.3.4.
Shared Files 408 6.3.5. Disk Space Management 410 6.3.6. File
System Reliability 416 6.3.7. File System Performance 424 6.3.8.
Log-Structured File Systems 428 6.4. EXAMPLE FILE SYSTEMS 430
6.4.1. CD-ROM File Systems 430 6.4.2. The CP/M File System 435
6.4.3. The MS-DOS File System 438 6.4.4. The Windows 98 File
System 442 6.4.5. The UNIX V7 File System 445 6.5. RESEARCH ON
FILE SYSTEMS 448 6.6 SUMMARY 448

CONTENTS XV 7 MULTIMEDIA OPERATING SYSTEMS 453 7. ]

INTRODUCTION TO MULTIMEDIA 454 7.2 MULTIMEDIA FILES 458
7.2.1. Audio Encoding 459 7.2.2. Video Encoding 461 7.3. VIDEO
COMPRESSION 463 7.3.1. The JPEG Standard 464 7.3.2. The MPEG
Standard 467 7.4. MULTIMEDIA PROCESS SCHEDULING 469 7.4.1.
Scheduling Homogeneous Processes 469 7.4.2. Genera] Real-Time
Scheduling 470 7.4.3. Rate Monotonic Scheduling 472 7.4.4. Earliest
Deadline First Scheduling 473 7.5. MULTIMEDIA FILE SYSTEM
PARADIGMS 475 7.5.1. VCR Control Functions 476 7.5.2. Near Video
on Demand 478 7.5.3. Near Video on Demand with VCR Functions
479 7.6. FILE PLACEMENT 481 7.6.1. Placing a File on a Single Disk
481 7.6.2. Two Alternative File Organization Strategies 482 7.6.3.
Placing Files for Near Video on Demand 486 7.6.4. Placing Multiple
Files on a Single Disk 487 7.6.5. Placing Files on Multiple Disks 490
7.7. CACHING 492 7.7.1. Block Caching 492 7.7.2. File Caching 494
7.8. DISK SCHEDULING FOR MULTIMEDIA 494 7.8.1. Static Disk
Scheduling 495 7.8.2. Dynamic Disk Scheduling 496 7.9. RESEARCH
ON MULTIMEDIA 498 7.10. SUMMARY 499

XVI CONTENTS 8 MULTIPLE PROCESSOR SYSTEMS 503 8.!.

MULTIPROCESSORS 506 8.1.!. Multiprocessor Hardware 506 8.1.2.
Multiprocessor Operating System Types 513 8.1.3. Multiprocessor
Synchronization 516 8.1.4. Multiprocessor Scheduling 521 tt.2.
MULT1COMPUTERS 526 8.2.1. Multicomputer Hardware 527 8.2.2.
Low-Level Communication Software. 531 8.2.3. User-Level
Communication Software 534 8.2.4. Remote Procedure Call 537
8.2.5. Distributed Shared Memory 540 8.2.6. Multicomputer
Scheduling 544 8.2.7. Load Balancing 545 8.3. DISTRIBUTED
SYSTEMS 549 8.3.1. Network Hardware 55 I 8.3.2. Network Services
and Protocols 553 8.3.3. Document-Based Middleware 558 8.3.4. File
System-Based Middleware 559 8.3.5. Shared Object-Based
Middleware 565 8.3.6. Coordmation-Based Middleware 572 8.4.
RESEARCH ON MULTIPLE PROCESSOR SYSTEMS 577 8.5. SUMMARY
577 SECURITY 583 9.1. THE SECURITY ENVIRONMENT 584 9.1.1.
Threats 584 9.1.2. Intruders 585 9.1.3. Accidental Data Loss 586
9.2. BASICS OF CRYPTOGRAPHY 587 9.2.1. Secret-Key Cryptography
588 9.2.2. Public-Key Cryptography 588

9.2.3. One-Way Functions 589 9.2.4. Digital Signatures 590 9 3.

USER AUTHENTICATION 591 9.3.!. Authentication Using Passwords,
592 9.3.2. Authentication Using a Physical Object 601 9.3.3.
Authentication Using Biometrics 603 9.3.4. Ccmniermeasures 606
9.4 ATTACKS FROM INSIDE THE SYSTEM 606 9.4.1. Trojan Horses
607 9.4.2. Login Spoofing 608 9.4.3. Logic Bombs 609 9.4.4. Trap
Doors 6!0 9.4.5. Buffer Overflow 610 9.4.6. Genene Security Attacks
613 9.4.7. Famous Security Flaws, 6!4 9.4.8. Design Principles for
Security 616 9.5. ATTACKS FROM OUTSIDE THE SYSTEM 6!7 9.5.1.
Virus Damage Scenarios 618 9.5.2. How Viruses Work 619 9.5.3.
How Viruses Spread 626 9.5.4. Antivirus, and Anti-Antivirus
Techniques 628 9.5.5. The Internet Worm 635 9-5.6. Mobile Code
637 9.5.7. Java Security 642 9.6. PROTECTION MECHANISMS 645
9.6.1. Protection Domains 645 9.6.2. Access Control Lists 647 9.6.3.
Capabilities 650 9.7. TRUSTED SYSTEMS 653 9.7.1. Trusted
Computing Base 654 9.7.2. Formal Models of Secure Systems 655
9.7.3. Multilevel Security 657 9.7.4. Orange Book Security 659 9.7.5.
Covert Channels 661 9 8. RESEARCH ON SECURITY 665 9.9.
SUMMARY 666

XVIII CONTENTS 10 CASE STUDY 1: UNIX AND LINUX 671 0 1

HISTORY OF UNIX 672 10. .1. 10.1.2. 10. 10. 10. 10. 10. .3. .4. .5.
.6. .7. UN1CS 672 PDP-11 UNIX Portable UNIX Berkeley UNIX
Standard UNIX MIN1X 677 Linux 678 673 674 675 676 !0 2.
OVERVIEW OF UNIX 681 10.2.1. UNIX Goals 681 10.2.2. Interfaces
to UNIX 682 10.2.3. The UNIX Shell 683 10.2.4. UNIX Utility
Programs 686 10.2.5. Kernel Structure 687 10.3. PROCESSES IN
UNIX 690 10.3.1. Fundamental Concepts 690 10.3.2. Process
Management System Calls in UNIX 692 10.3.3. Implementation of
Processes in UNIX 699 10.3.4. Booting UNIX 708 10.4. MEMORY
MANAGEMENT IN UNIX 710 10.4.1. Fundamental Concepts 71!
10.4.2. Memory Management System Calls in UNIX 714 10.4.3.
Implementation of Memory Management in UNIX 715 10.5.
INPUT/OUTPUT IN UNIX 723 10.5.1. Fundamental Concepts 724
10.5.2. Inpui/Output System Calls in UNIX 726 10.5.3.
Implementation of Input/Output m UNIX 727 10.5.4. Streams 730
10.6. THE UNIX FILE SYSTEM 732 10.6.1. Fundamental Concepts
732 10.6.2. File System Calls in UNIX 736 10-6.3. Implementation of
the UNIX File System 10.6.4. NFS: The Network File System 747

CONTENTS 10.7. SECURITY IN UNIX 753 10-7.1. Fundamental

Concepts 753 10.7-2. Security System Calls in UNIX 755 10.7-3.
Implementation of Security in UNIX 756 108 SUMMARY 757 11 CASE
STUDY 2: WINDOWS 2000 763 11.I. HISTORY OF WINDOWS 2000
763 ll.I.K MS-DOS 763 11.1.2. Windows 95/98/Me 764 11.1.3.
WindowsNT 765 11.1.4. Windows 2000 767 11.2. PROGRAMMING
WINDOWS 2000 771 11.2.1. The Win32 Application Programming
Interface 772 11.2.2. The Registry 774 11.3. SYSTEM STRUCTURE
778 11.3.1. Operating System Structure 778 11.3.2. Implementation
of Objects 787 11.3.3. Environment Subsystems 792 11.4.
PROCESSES AND THREADS IN WINDOWS 2000 796 11.4.1.
Fundamental Concepts 796 11.4.2. Job, Process, Thread and Fiber
Management API Calls 799 11.4.3. Implementation of Processes and
Threads 802 11.4.4. MS-DOS Emulation 809 11.4.5. Booting
Windows 2000 820 11.5. MEMORY MANAGEMENT 811 11-5.1.
Fundamental Concepts 812 11.5.2. Memory Management System
Calls 816 11.5.3. Implementation of Memory Management 8l7 11.6.
INPUT/OUTPUT IN WINDOWS 2000 824 1 1.6.1. Fundamental
Concepts 824 11.6.2. Input/Output API Calls 825 11.6.3.
Implementation of I/O 827 11.6.4. Device Drivers 827

CONTENTS 11.7. THE WINDOWS 2000 FILE SYSTEM 830 11.7.1.

Fundamental Concepts 830 t 1.7 2. Rte System API Calls in Windows
2000 83 t 117.3. Implementation of the Windows 2000 File System
833 118. SECURITY IN WINDOWS 2000 844 11.8.1. Fundamental
Concepts H45 11.8.2. Security API Calls 847 11.8.3. Implementation
of Security 84* 11.9. CACHING IN WINDOWS 2000 849 tl 10.
SUMMARY 851 12 OPERATING SYSTEM DESIGN 855 I2.I. THE
NATURE OF THE DESIGN PROBLEM 856 12.1.1. Goals 856 12.1.2.
Why.is i! Hard to Design an Operating Systems'' 857 12 2.
INTERFACE DESIGN 859 12.2.1. Guiding Principles 859 12.2.2.
Paradigms 861 12.2.3. The System Call Interface 864 12.3
IMPLEMENTATION 867 12.3.1. System Structure 867 12.3.2.
Mechanism versus Policy 870 12.3.3. Orthogonality 871 12.3.4.
Naming 872 12.3.5. Binding Time 874 12.3.6. Static versus Dynamic
Structures 875 12.3.7. Top-Down versus Bottom-Up Implementation
876 12.3.8. Useful Techniques 877 12.4. PERFORMANCE 882 12.4.1.
Why are Operating Systems Slow? 882 12.4.2. What Should be
Optimized? 883 12.43. Space-Time Trade-offs 884 12.4.4. Caching
887

12.4.5. Hints 888 12.4.6. Exploiting Locality 888 12.4.7. Optimize the
Common Case 889 12.5. PROJECT MANAGEMENT 889 12,5.1 The
Mythical Man Month 890 12.5.2. Team Structure 891 125.3. The
Rote of Experience 893 12 5.4. No Silver Buttet 894 12.6. TRENDS
tN OPERATING SYSTEM DESIGN 894 12.6.1. Large Address Space
Operating Systems, 894 12.6 2. Networking 895 12.6.3. Parallel and
Distributed Systems 896 12.6.4. Multimedia 896 12.6.5. Battery-
Powered Computers 896 12.6.6. Embedded Systems 897 12.7.
SUMMARY 897 13 READING LIST AND BIBLIOGRAPHY 13.1.
SUGGESTIONS FOR FURTHER READING 901 .1. Introduction and
General Works 902 .2. Processes and Threads 902 .3. Deadlocks 903
.4. Memory Management 9A3 .5. Input/Output 903 .6. File Systems
904 .7. Multimedia Operating Systems 905 .8. Multiple Processor
Systems 906 .9. Secunly 9(>7 .10. UNIX and Linux 908 .11.
Windows 2000 909 .12. Design Principles 910 13.2 ALPHABETICAL
BIBLIOGRAPHY 911 901 INDEX 935

1 INTRODUCTION A modem computer system consists of one or

more processors ome main memory, disks, printers, a keyboard, a
display, network interfaces, and other input/output devices. All in all,
a complex system. Writing programs that keep track of all these
components and use them correctly, let alone optimally, is an
extremely difficult job. For this reason, computers are equipped with
a layer of software called the operating system, whose job is to
manage alt these devices and provide user programs with a simpler
interface to the hardware. These sys- systems are the subject of
this, book. The placement of the operating system is shown in Fig I
-1. At the bottom is the hardware, which, in many cases, is itself
composed of two or more levels (or layers). The lowest level
contains physical devices, consisting of integrated cir- circuit chips,
wires, power supplies, cathode ray tubes, and similar physical
devices. How these are constructed and how they work are the
provinces Of the electrical engineer. Next comes the
microarchitecture level, in which the physical devices are grouped
together to form functional units. Typically this level contains some
reg- registers internal to the CPU (Central Processing Unit) and a
data path containing an arithmetic logic unit. In each clock cycle,
one or two operands are fetched from the registers and combined in
the arithmelic logic unil (for example, by dddition or Boolean AND).
The result is stored in one or more registers. On some machines, the
operation of the data path is controlled by software, called the
microprogram. On other machines, it is controlled directly by
hardware circuits. 1

Banking system Cow*, reser Edi anon „„ Web Command inlerpreler

Operating syslem no- Physical anguage iteclure devices The purpose
of the data padi is to execute some set of instructions. Some of
these can be carried out in one data path cycle; others may require
multiple data path cycles. These instructions may use registers or
other hardware facilities Together, the hardware and instructions
visible to an assembly language program- programmer form the ISA
(Instruction Set Architecture) level. This level is ofien called machine
language. The machine language iypically has between 50 and 300
instructions, mostly for moving data around the machine, doing
arithmetic, and comparing values. In this level, the input/output
devices are controlled by loading values into special device registers.
For example, a disk can be commanded to read b> loading Ihe
values of the disk address, main memory address, byte count, and
direction (read or write) into its registers. In practice, many more
parameters are needed, and the status returned by the drive afier an
operation is highly complex Furthermore, for many I/O
(Input/Output) devices, timing plays an important role in the
program- programming. To hide this complexity, an operating system
is provided. It consists ot a layer of software that (partially) hides
the hardware and gives the programmer a more convenient set of
instructions to work with. For example, read block from file is
conceptually simpler than having to worrj about die details ot
moving disk heads, waiting for them to settle down, and so on. On
top of the operating system is the re^t of the system software Here
we: find ihe command interpreter (shell), window systems,
compilers, editors, and similar application-independent programs H
is important 10 realize thai the>e programs are definitely not part of
the operating system, even though ihey are typ- typically supplied by
the computer manufacturer This is a crucial, hut subile, point The
operaiing system is (usually) ihat portion ol the software ihat runs in
kernel mode or supervisor mode. Ii is protected from user tampering
by the hardware (ignoring for the moment some older or low-end
microprocessors thai do nol have

hardware protection at all)- Compilers and editors run in user mode.

It a user does not like a particular compiler, het is free to write his
own if he so chooses; he is not free to write his own clock interrupt
handier, which is part of the operat- operating system and is
normally protected by hardware against attempts by users to modify
it. This distinction, however, is sometimes blurred in embedded
systems (which may not have kernel mode) or interpreted systems
(such as Java-based operating systems that use interpretation, not
hardware, to separate the components). Still, for traditional
computers, the operating system is what runs in kernel mode. That
said, in many systems there are programs that run in user mode but
which help the operating syslem or perform privileged functions- For
example, there is often a program that allows users to change theii
passwords. This pro- program is not part of the operating system
and does not run in kernel mode, but it clearly carries out a sensitive
function and has to be protected in a special way. In some systems,
this idea is carried to an extreme form, and pieces of whai is
traditionally considered to be the operating system (such as the file
system) run in user space. In such systems, it is difficult to draw a
clear boundary Everything running in kernel mode is clearly part of
the operating system, but some prograns running outside it are
arguably also part of it, or at least closely associated with it. Finally,
above the system programs come the application programs. These
programs are purchased or written by the users to solve their
particular problems, such as word processing, spreadsheets,
engineering calculations, or storing infor- information in a database.
1.1 WHAT IS AN OPERATING SYSTEM? Most computer users have
had some experience with an operating system, but it is difficult to
pin down precisely what an operating system is. Part of the prob-
problem is that operating systems perform two basically unrelated
functions, extending the machine and managing resources, and
depending on who is doing the talking, you hear mostly about one
function or the other. Let us now look at both. 1.1.1 The Operating
System as an Extended Machine As mentioned earlier, the
architecture (instruction set. memory organization, I/O, and bus
structure) of most computers at the machine language level is primi-
primitive and awkward to program, especially tor input/output. To
make this point more concrete, let us briefly look at how floppy disk
I/O is done using the NEC t "He" should be read as "he ar she"
throughout the book

4 INTRODUCTION CHAP. 1 PD761) compatible controller chips used

on inosi Intel-based personal computers. (Throughout this book we
will use the terms "floppy disk" and "diskette'" inter-
interchangeably.) The PD765 has 16 command*, each specified by
loading between 1 and 9 bytes inio a device register These
commands are for reading and writing data, moving the disk arm,
and formatting tracks, as well as initializing, sensing, resetting, and
recalibrating the controller anil tbe drives The most basic commands
are read and write, each of whicb requires 13 parameters, packed
into 9 bytes. These parameters specity such items a.s the address of
[he disk block !o be read, the numher of sectors per (rack, the
recording mode used on the physical medium, lhe miersecior gap
spacing, and whai lo do with a deleted-data-address-mark. If you do
not undersland thts mumbo jumbo, do no! worry, lhat is precisely
(he poinl—i! is raiher esoteric. When lhe operation is completed, lhe
controller chip reiurns 23 status and emir fields packed into 7 bytes.
As if this were not enough, lhe floppy disk programmer must also be
con- stanily aware of whether the motor is on or off If ihe motor is
off, u must be turned on (with a long startup delay) before data can
be read or written The motor cannot be left on too long, however, or
ihe floppy disk will \«ar out The programmer is thus forced to deal
with tbe trade-off beiween long startup delays versus wearing out
floppy disks (and losing ihe data on (hem). Without going into lhe
real details, it should be clear thai (he average pro- programmer
probably does not want to get too intnnaiely involved with the
program- programming of floppy disks (or hard disks, which arc just
as complex and quite dif- ferenl). Instead, what the programmer
wants is a simple, high-level abstraction to deal with. In the case of
disks, a typical abstraction would be tba( lhe dtsk con- contains a
collection of named files. Each file can be opened tor leading or
writing, lhen read or written, and finally closed. De(ails such as
whether or not recording should use modified frequency modulation
and what lhe current slate of (lie motor is should not appear in the
abstraction presented lo (he user The program lhat hides the trulh
about the hardware from the programmer and presents a nice,
simple view of named files lhai can be read and written is, of course,
the operating system. Just as lhe operating system shields (he
programmer from ihe disk hardware and presents a simple file-
oriented interface, it also con- conceals a lot of unpleasant business
concerning interrupts, timers, memory manage- management, and
other low-level features. In each case, the abstraction offered by the
operating system is simpler and easier to use than that ottered hy
the underlying hardware. !n this view, the function of lhe operating
system is lo prcsenl lhe user with the equivalent of an extended
machine or virtual machine that is easier to pro- program than the
underlying hardware. How the operating system achieves this goal is
a Jong story, which we will study in detail throughout this book Tu
summarize it in a nutshelf, the operating system provides a variety
or services that programs can ohtain using special instructions called
system calls. We will examine some of the more common system
talfs later in this chapter

SEC I I WHAT IS AN OPERATING SYSTEM ' 5 1.1.2 The Operating

System as a Resource Manager The concepi ot lhe operating system
as primarily providing its users wtih a convenient interface is a top-
down view, A.n alternative, bottom-up, view holds lhat lhe operating
system is there to manage all lhc pieces ot a complex system.
Modem computer;, consist or processors, memories, timers, disks,
mice, network interfaces, print-*;,, and a wide variety of other
devices. In the alternative view, the job or lhe operating system is to
provide lor an orderly and controlled alloca- allocation of lhe
processors memories, and I/O devices among lhe various programs
competing for them. Imagine what would happen if three programs
running on some computer all tried to print their output
simultaneously on the same printer The first lew lines of printout
might be from program i, the next few from program 2, then some
rrom program 3, and so forth. The result would be chaos. The
operating system can bring order to the potential chaos by buffering
all the output destined for lhe primer on the disk. When one
program is finished, the Operating system can then copy its ouiput
from the disk file where it has been stored to the printer, while at
the same time the other program can continue generating more
output, oblivious to the tact that the output is not really going to the
printer (yet) When a computer (or network) has multiple users, the
need for managing and protecting the memory, I/O devices, and
other resources is even greater, since the users might otherwise
interfere with one another. In addition, users often need to share not
only hardware, but information (files, databases, etc.) as well. In
short, this view of the operating system holds that its primary task is
to keep track i>f who is using which resource, to grant resource
requests, to account for usage, and to mediate conflicting requests
from different programs and users- Resource management includes
multiplexing (sharing) lesources in two ways: m time and in space.
When a resource is time multiplexed, different programs or users
take turns using it. First one ot them gets to use the resource, then
another, and so on. For example, with only one CPl) and multiple
programs that warn to run on it. the operating system first allocates
lhe CPU to ooe program, men after it has run long enough, another
one gets to use the CPU, then another, and then eventually the first
one again. Determining how the resource is time multi- multiplexed
—who goes next and for how long—is the task of me operating
system. Another example of time multiplexing is sharing the prititer
When multiple print jobs are queued up for printing on a single
printer, a decision has to be made about which one is to be printed
next. The other kind ot multiplexing is space multiplexing Instead of
the custo- customers taking turns;, each one gets part of the
resource. For example, mam memory is normally divided up among
several running programs, so each one can he resident at the same
time (for example, in order to take turns using the CPU). Assuming
there is enough memory to hold multiple programs, it is more
efficient to hold several programs in memory at once rather than
give one of them all of it,

6 INTRODI'CIION rH'xP ' especially 11 11 only nwds a small rnicnuU

of the total Ol touisc. this taises issues ot' laimes.s, prorectton, and
so on. and ii is up Id the operating system lo solve them Another
resource that is space multiplexed is :he (hard) disk. In m<m>
svsrems a single disk can hold files flora manj user, at the same
ltme. Allocating disk <paee and keeping irack of who is using which
disk blocks is i tjpical operating system lesource management task.
1.2 HISTORY OF OPERATING SYSTEMS Operating s>sIlhis huvu
been evolving ilmiugh the yen-, In the lollowinj sections we will
bnefl> look at a few ot the highlights. Since operating systems have
historically been closely tied tn the jichiiecmre ot the compuiei s on
which Ihey run. we will look ai successive generations ot computers
10 see what theif operating systems were like This mapping of
operating system gencianoliS io compulei generations is Lrude. but U
docs provide some strutiurc where thec- would otherwise be none
The firsi ime digual compuier was designed by the English
mmheiiutic-ian Charles Babbage A792-1871) Although B.ibbage
speni most ot his life and lor- tune trying to build his 'analytical
engine." he never got it working properlv hecause u was purely
mechanical, and the technology of his day could noi pro- produce
the required wheels, gears, and cogs to llic high precision lhal he
needed Needles to say. the analytical engine did not have an
operating system As an interesting historical aside. Bahbagc re;ihzcd
thai he would need software for his analytical engine, so lit- hned .i
young woman named Adj Lovelace, who was the daughier of the
tamed Bniish poel Lord Bjron. as lhe world's tirsl programmer The
programming language Adac" is named afiei her 1.2.1 The First
Generation A945-55) Vacuum Tubes and Plugboards A Her
Babbage's unsuccessful efforts, liulc progress v,as made in
consirudin.4 digital computers unli) Wi)rld Wai II Around the tiHc!-
l94Os, Howard Aikcii at Harvard, John von Neam.inn a! the lnstiiule
tor Advanced Sludy in PrUicetoii. J. Presper Eckert and William
Mautfiley <t! the Uttn-ersiiy <il Penitsyhania. and Konrad Zuse in
Germanv, among others, all succeeded in building calculating
engines. The first ones used mechanical relays hut were eery slow,
wiih cycle times, measured in seconds Relays were laier leplaced by
vacuum tubes Iliese machines were enormous, tilling up entire
roams with tens ot thousands of vacuum tubes, but they were still
millions ot times slawer than even the cheapest personal computers
available loday. In these early days, a single group ol people
designed, huilt, programmed, operated, and maintained each
machine. All programming was done in absolute

machine language, otten by wiring up plugboards to control Ihe

machine's haste fundsFX1. Programming languages were unknown
(even assembly language was unknown). Operating sysiems were
unheard ot. The usual mode ol operation was for ibe programmer to
sign up for a block ot time on the signup sheet on the wall, then
come down 10 the machine room, itisert his or her plugboaid into
lhe com- puier, and spend ihe next tew hours hoping that none ol
the 20,000 or so vacuum tubes would burn oui during the run
Virtually all the problems were straightfor- straightforward numerical
calculations, such as grinding oui tables of sines, cosines, and log-
logarithm <; By the early 1950s, ihe routine had (mpioved
somewhat with tile introduction of punched cards. 1! was now
possible to write progiams on curd.s and read them in instead of
using plugboards; otherwise, the procedure was the saiiie 1.2.2 The
Second Generation A955-65) Transistors and Batch Systems The
introduction of ihe transistor in the mid-1950s changed the picture
radi- radically Computers became reliable enough that they could be-
manufactured and .sold (o paying customers with the expectation
that they would Continue to func- function long enough to get some
useful work done. For the tir.st time, there wat, a clear separation
between designers, builders, operators, programmers, and mainte-
maintenance personnel. These machines, now called mainframes,
were locked away in specially air conditioned computer rooms, with
staffs ot professional operators to run them- Only big corporations or
major government agencies or universities could afford the
multimillion dollar price tag. To run a job lie.a program or sei of pro-
programs), a programmer would first write the program on paper (in
FORTRAN or assembler), then punch it on cards. He would then
bring the curd deck down io Ihe input room and hand it to one of
the opeiators and go drink coffee until the output was ready. When
the computer finished whatever joh it was currently running, an
opera- operator would go over to the printer and tear off the output
and carry it over to the out- output room, so that the programmer
could collect it later Then he would take one of the card decks that
had been brought trom the input room and read it in. If the
FORTRAN compiler was needed, the operator would have to get it
trom a file cabinet and read it in. Much computer time was wasted
while operators were walking around the machine room- Given the
high cost of the equipment, it is not surprising that people quickly
looked for ways to reduce the wasted time The solution generally
adopted was the batch system. The idea behind it wa? to collect a
tray full of robs in the input room and then read them onto a
magnetic tape using a small (relatively) inexpen- inexpensive
computer, such as the IBM 1401, which was very good at reading
cards, copying tapes, and printing output, but not at all good at
numerical calculations.

8 INTRODUCTION CHAP Oihcr. much moic expensive machines, siich

as ihe IBM 7094. were usedfoi t real compnting. This situation is
shown in Fit;. 1-2. Figure 1-2. An uirlj bi1Lh '.yslan (a) Prc 1401
Itfjdi ba*li of lobs onto Upi- (c) Ope 7094 Joes computing (e)
Operator carries ■ @ 1401 print- After aboul an hour of collecting a
baler* of |<>hs. Ihe lapc was rewocind and brought into the
machine rc.i.m, where n wa> mountt-d cm a tape drive. Ttie opera-
operator then loaded a .special program (the anceslor of Hidays
operating sysiem). which read the first job Ironi tape and ran it The
output wlw written onto a sec- second tape, instead of being
printed. Aftei each job finished. Ihe operating system automatically
read the next job from Ihe tape and began ronnmg H. Wlien I he
whole hate the input tape with the next batch, and brought the
output 1. ing off line (i.e.. not connected to the main computer)
1401 The net] i $JOB card, specifying the maximum run tune m
minutes, th be charged, and the pioeramnier's name. Tiien can.e a
$F0RTRAN curd, the operating system to load the FORTRAN
compiler from the system was followed by the program to he
compiled, and then a SLOAD card, the operating system to load the
object |irdgraii> |iist compiled (Coinpi grams were often written i,n
scratch tapes and liad to he li.aJed exj)licitl> came the $RUN caid,
telling the operating systen, to run ihe program data ioliowing it
Finalh, the $END caid maiked the end i,f the ji.h. The itive control
cards were the fmerunners or nicdern |Ob eontrol languages a mand
interpret ir pntit- nberto telims ■ipe Tt renting >d pro- ) Next ■ith
tne nd-ge i mputers engiueenng cakuiations. such as solving tile
partial chf|erential equati often occur in physics and engineering
They v,L-ic largely progianinieiJ TRAK and assembly language.
Typical operaiing systems were FMS (the Monitor System) 3nd
IBSYS, IBM's operating system for the 7094. ns that n FOR- F-ortr.in

HISTORY OF OPERATING SYSTEMS 1.2.3 The Third Generation

A965-1980) ICs and Multiprogramming By ihe early 1960s, most
computer manufacturers had two distinct, and tolaiiy incompatible,
produci lines. On the one hand thcie were ihc wcird-tinemed. large-
scale scientific computers, such as the 7094, which were used tor
numerical calculations in science and engineering. On the other
hand, there were the character-oriented, commercial computers,
such as 'he 1401, which were widely used tor tape sorting and
printing by hanks and insurance companies Developing and
maintaining two completely different product lines was ai>
expensive proposition for the manufacturers In addition, many new
ci.n.puter customers initially needed a small machine but later
outgrew it and wanted a bigger machine that would run al! their old
programs, hut faster IBM attempted 10 si.lve both of these problems
ai a single stroke by introduc- introducing the Systetn/360. The 360
was a series ot sotiware-conipatibk.- machines rang- ranging from
1401-sized ti, much more powerful llian the 7094 The machines dif-
differed (inly in piicc and performance (maximum memtiiv, processor
speed. nu,Tihcr of I/O devices permitic-d, and so forth) Since all tl>e
machines had ihL- same architecture and instruction set, programs
wmiei, ior one n.aehme amliT run on all the others, at least in
lhcory. Funherm<,re. ihe 3M> was designed to handle both scientific
(i.e , numerical) and commercial computing Thus a single family of
machines could satisfy the needs of all customers In subsequent
years, IBM has ci.me out with compatihle successors to the- 160
line, using more nu.dern ic-cTinuT- ogy, known as the 370.
4300.10SO, and 1090 series

10 iNTkODLC I ION t-'UAP I Tlit- 360 was (he tusi majoi computer
lino to use (small scale) Integrated Or- cuit*. <rCV. thus providing a
major price/performance ;tdv;inlage o\er the second- generation
machines. v\mdi were built up from indiwdu.il transistors, ll was an
adopted by all lhe other majoi manufacturers The descendants of
these machines are stili in use ,il computer centers today. Nowadays
they are often used lor World Wide Weh site thai must pioccss
thi.usarids cif requests j,er second. fhf greatest strength of the "one
tamtl) ' idea was simultaneously its greatest weakness. The intention
w.is thai all softwaie. including the operating system, OS/360 had to
work on all i.iodel.s It had 10 ruti on small systems, whicn often lust
replaced 1401s for copying aircis tu tape, and on very laigc systems,
which often replaced 7094s lor doing weather forecasting and other
heavy computing It had tu be good oti .systems with tew peripherals
and on systems with nwuv pen- menis. Abo\eall, it had to be
clTtcient for all elf these JtfteretitiK.es. There was no way that IBM
(Or anybody else) UiUlci wine a piece Ol software to meet ad (hose
conflicting requirements The result was an enormous and
extraordinarily eotnplex operating system, piobalJy two to thiec
orders ol magni- magnitude larger than FMS ll consisted or millions
ot Imps of assembly language writ- written by thousands of
programmers, ,md contained thousands upon (housaiids of bugs,
which necessitated a continuous stream ol" new releases ui an
attempt to correct then,. Each new iclease fixed some bugs and
introduced new ones, so the numher ol bugs probabl; remained
constant m time One ot the designers ot OS/360. Fred Biooks,
subsequently wiole a witty and incisive book (Brooks, 1996)
describing his experiences with OS/lfn). While it would be impossible
to summarize the hook heie. suffice i( to say that the cci\er shows a
herd of prehistoric beasts siutk in ,i lai |iil. The cover ot Silherschat7
el al. B000) makes a similar point about tij.erating systems beina
dmos.»irs. Despite its enormous size and problems. OS/3W) and the
similai thud- getieratn>fl operatjng syst^ins produced by other
comiiUler inaiiLiIucliirers actually sjtisfied most oi their customers,
reasonably well- They also popularized seveial key techniques ahsent
in seconci-getieiaiion ojieratmg systenis Probably the must important
ot these was multiprogramming. On the 7094, when tlvc current job
paused to wait for a tape or other i/O operation hi complex, the CPU
simply sal idle until the I/O finished With heavily CPU-l.ound
scientific calculations I/O is infrequent, so this wasted tune is not
signitkani With conimeicial data pioccss- mg, the I/O wait time can
often be- 80 or 90 peicent of the toi.il time, so something had to be
done to avoid having lhe (expensivei CPV be idle so much different
job in each petition, .is shown in Fig 1-4 While one job was waiting
toi I/O lo complete, another job could be Using the <L PL) It enough
)tibs could |,e held in main memory at once, the CpU could he kept
busy nearly 100 percent of

SEC ( 2 HISTORY OF OPERATING SYSTFMS II the lime Having

multiple jobs safely in memory a! once require-, special hardware to
protect each job against snooping and mischief by the other ones,
but (he 360 and other mird-generation systems were equipped with
(his hardware. ability to omputcr Figure !»4- A nuifiiprogramniiug
syMCiii \wrh rhrtv )vb<> ill mernor\. r major feature present in
third-generation operating systems was the :ad jobs from cards onto
the disk as soon as they were brought to tlie Then, whenever a
running job finished, the operating syst p g j could load a new job
from the disk into the now-empty partition and inn ii This technique
is called spooling (from Simultaneous Peripheral Operation On t.ine)
and was also used for output. With spooling, the T40)s were no
longer needed, and much carrying of tapes disappeared. Although
third-geneiation operating systems were wen suiic-d for big scic tific
i pn.c still basically batch systems. Many programmers' pined for the
first-generaturn days when they had the machine all to themselves
for a few hours, so they could debug their programs quickly. With
third-generation systems, the time between suhmit- ting a job and
getting back the output was, often several hours, so a single mis-
misplaced comma could cause a compilation to fail, and the
programmer t<i waste half a day. This desire for quick response time
paved the way toi timesharing, a variant of multiprogramming, in
which each u^ei has an online terminal In a timesharing system, if
20 users are logged in and 17 of them are thinking or talking 01
drinking coffee, the CPU can be allocated in turn to the three jobs
that want service Since people debugging programs usually issue
short commands (e.g. compile a five- page proceduret) rather than
long ones (e.g., sort a mil lion-record file), the com- computer can
provide fast, interactive service to a number of users and perhaps
also work on big batch jobs in the background when the CPU is
otherwise idle The first serious timesharing system. CTSS
(Compatible Time Sharing System), w,ts developed at M.l.T. on a
specially modified 7094 (Corbato et al . 1962). How- However,
timesharing did not really become popular until the necessary
protection hardware became widespread during the third generation.
is "procedure." "subrouliiie." and " iterclungeabty ir

12 INTRODUCTION <-HAP I After tke success 01 thi- CT&S system.

MIT. Bell Labh, am) Genei.il fclectnc (then a major computer
m.mufactuier) decided to embark on the development of a
•■a.mputcr utility." a machine that would suppoit hnmlieds (,f
simultaneous need electric power. >on just stick a plug m Uie wall,
and within reason, as much pown as you need will l,e there The
designers or this system, known as Ml'L- TICS (>U'LTiplexed
Information and Computing Ser\k-t). envisioned one hugt' machine
fiioviding computing power tor everyone in ihe Boston area The idea
fliat machines far more powerful than their GE-645 mainframe would
he sold t(,r ,i thousand dollars b> thi- millions only 10 years later
w<is pure science fiction. on a inahinc onlj slightly rnore powerful
th.in an Intel 386-hasei1 PC, although it had much more I/O
capacity This is not quite as cra^y its it sounds, since people- knew
how to write small, efficient programs tu those days, a skill that has
suhse- quenlly heen lost. There were many reason-, that MULTlCS
did not t;ike over the world, not the least of which is that it was
written in VIA. and the VIA compiler H'*is years tale and bare I v
worked at alt when it finally arrived In addition. Ml L- ical engine in
the nineteenth century To make a long story short. MULTlCS
introduced many seminal ideas into the computer literature, but
tunnng it into a serious [iroduet and a ma tor commeruat su^eess
was a lot harder than anyone had r\pccreil. Bell Labs1 dropped out
of the project, and General Elecinc quit the computer business
.dlogeihei. However, M.I.T. persisted and eventually got MULTlCS
working It was lihimaiety sold as a commercial product by the
company that honght Gt's computer business (Honeywell) and
installed by aboul 80 major companies and universities world-
worldwide While their numhert, were small. MLJt TICS users were
fiercely toyat Gen- General Motors. Ford, and the (J S Nalionat
Security Aecnc>. ti.r example, only sfiut down their MUl.TlCS iysien»
'» the tate tWOs, 10 years ,ittci Ml'LTKS was released For the
moment, the concept or a uompuici utility has hzzled out but it may
well come back in the form of massive centralized internet servers to
which reta- lively dumb user machines are attached, with mosl of
the work happening on the big .servers. The motivation here is tikely
to he that mosl peoptc do not wiint to administrate an increasingly
complex and dnrcky computer system and would prefer to have thai
work done by a team »f pujressionals woiking for the company
running the server E-eommeree is already evolving in Ihrs direction,
with various companies running e-mail^ on multiprocessor servers
to which sinipte ctienl machines connect, very much in the spirit <)f
the MULTlCS oV'simI1 Despite its lack of commercial success.
MfLTlCS had a huge inJlni-ncc on subsequent operating systems It
is1 desenhed in (Corbato el al.. £972. Corbato and Vyssolsky, 1965;
Daley and Dennis,. 1968; Organick. 1972; and Saltzer, 1974). It

HISTORY OF OPERATING SYSTEMS 13 Weh site, vww. multn

iam.o>g, with a great deal of informa- information about ihc system,
ifs designed, and its users. Another major development during the
third generation was the phenomenal growth of minicomputers,
starting with the DEC PDP-1 in 1961. The PDP-i had only 4K of 18-
bif words, but at S12(),(X)t> per machine (less than 5 percent of the
price or J 7094). it sold like hotcakes. For certain kinds of
nonnumencal work, it was ,ilm<iM as fjsi as (he 7094 and gave birth
to a whole new industry. It was quickly followed by a series ot other
PDPs (unlike IBM's family, all incompati- incompatible! culminating in
the I'DP-| | One ol the computer scientist <*l Bell Labs who had
worked on the MULTICS project. Ken Thompson, subsequently found
a small pDP-7 minicomputer that no one was using and ^,ct out to
write a stripped-down, one-user version of MULTICS. This work later
developed into the UNIX operating system, which became popu-
popular in the academic world, with government agencies, and with
many companies. The history of UNIX has been told eisewheie (e.g.,
Salu.s, 1994). Part of that story will be given in Chap. 10. For now,
suffice it to say. that because the source code was widely available,
various organisations developed their own (incompati-
(incompatible) versions, which led to chads Two major versions
developed. System V. from AT&T, and BSD, (Berkeley Software
Distribution) Ironi the Universiiy of California at Berkeley. These had
minor variants as well. To make ilpossihle to write programs that
could run on any UNIX system. IEEE developed a standard for UNIX,
called POSIX. that most versions of UNIX now support. POSIX
defines a minimal system call interface that conformant UNIX
system*, must support. In fact, some other operating systems now
also support the POSIX interface. As an aside, it is worth meniioning
that in 1987, the author released a small clone of UNIX, called
M1NIX, for educational purposes. Functionally. MINIX is very similar
to UNtX, including POSIX support A book describing Us internal
operation and listing the source code in an appendix is also available
(Tanenbaum and Woodhull, 1997) MINK is available for free
(including all the source code) over the Internet at URL
www.ci.vu.nl/~ast/mim\.hrml The desire for a free production (as
opposed to educational) version ot MINlX led a Finnish student,
Linus Top/aids, to write Linux This system was developed on MINIX
and originally supported various MINIX features (eg . the MtNtX fite
system) It has since been extended in many ways out still retains a
laige amount of underlying slructure common to MINIX, and to UNIX
(upon which toe former was based). Most of what will lie said about
UNIX in this book thus applies to System V, BSD. MINIX, Linux, and
other versions and clones of UNIX as well. 1.2.4 The Fourth
Generation A980-Present) Persona! Computers With die
development of LSI (Large Scale Integration) circuits, chips contain-
containing thousands of transistors on a square centimeter ot silicon,
the age of the per- personal computer dawned In terms of
architecture, personal computers ^initially

14 INTRODUCTION rii\l> ' tailed microcomputers i weie not all

tb<<f dJ'tuent trom minicomputers of the PDP-11 class, but tn
term;, ol price they eeitamly weic dittl-rent Whole the mini-
minicomputer made ttpos'sibbforadepajdnent <n a company or
iini\ersit> lo have it, own computei, the microprocessor cl.fp made H
pos-ible for a single individual <o have bis m her own personal
computer In (974, when Intel came out with the 8f)8(), the first
genei;il-purpo--e 8-bit CPU, it wanted an operating system for the
8080. in part fo he able to test if. Intel ;,<.ked (."e of its
consultants. Gary Kildall. t(i write one Kitdall and a friend first built a
controller tortlie newly-released Sbug.irt Associates 8 inch floppy
disk and hooked the floppy disk up fo the 8080, thus producing the
first micr<ic<>tnputei wiib a dt.sk. Kildall (hen wrote a disk-based
operating system called CP/M (Con- (Control Program for
Microcomputers) (or it Since Intel did not think that disk- b;tsed
microcomputers, lidd much of a future, ^hen Kildall asked for the
rights so CP/M. Intel granted fus request Kildall then formed J
Loinp.iny. Digital Research, to further develop and sell CP/M In (977,
Digital Research it wrote CP/M to m;ike if suitable tor running on (he
many microcomputers using the K080, Zifoe Z80. an(l otfiet CPU
cbips~ Many application programs were written to run on CP/M,
allowing <t to complete!) dominate the world of microeompudng tor
about 5 yens In trie early 1980s. IBM designed the IBM PC and
looked around for software to run on if. People from IBM contacted
Bill Gale* io license bis BASIC1 mtei- preter. They also asked him if
he knew of an operating system fo run un the PC Gates suggested
that |BM contact Digital Research, then the world"-, dominant
operating systems company. Making ivbai was surely the worst
business decision in recorded history, Kildall refused to tired with
IBM, sending ,i subordinate instead. To make matters worse, bis
lawyer even refused to sign IBM's nondis- nondisclosure agreement
covenng (he no(-yei-anm>unced CC Consequently, IBM went back
to Gates asking if be could provide them w tth an opcr.rtitig system
When IBM came back, Ga(es realized tliat ;t loc.if eoniputei
manufacturer, Seattle Computer Produce, bad a suUable operating
system. DOS (Disk Operat- Operating System). He approached them
and asked to buy it (allegedly for $50,000), which they readily
,tecep(ed. Ga(es then offered IBM a DOS/BASIC package, which IBM
accepted. IBM wanted certain ino<l ill eat tons, --o Gates hired (he
per- person who wrote DOS, Tim Paletson. as an employee of Gales
fledgling company, Microsoft, to make (hem The revised system w,,s
renamed MS-DOS (MicroSoft Disk Operating System) and quickly
came io dominate ific IBM PC market \ key factor here was Gates' (in
retrospect, extremely wisei decision to ,ell MS- DOS to compiler
companies loi butidlnu' with then hardwaie. etunpared to Ki!(fa!l'!>
atfeaip( to sell CP/M to end users- one at tt time (af least uiitiall> )
By the fmie the IBM PC7AT carae out jn 1983 wr(h the Intel 80286
CPU, MS-DOS was fumly entrenched and CP/M v>as on its last leg--
MS DOS was Uter widely used on the 8(^86 and 80486 Although the
initial version ot MS-IXJS w,is fairly pntnrtivc, suhsequenf versions
included more advanced features, including

SFC f 2 HISTORY OF OPERATING SYSl'LMS 15 many taken from

UNIX (Microsoft was well aware ot UNIX, even selling a
microcomputer version of it called XENIX during ihc company's early
years.) CP/M. MS-DOS, and otlicr opera! ing systems for early
microcomputers were .til based on users typing in commands from
ihe keyboard- That eveniuaHy Lhanged due (o research done by
Doug Engelbart at Stanford Research Institute in the 1960s.
Engelbart invented the GUI (Graphical User Interface), pronounced
"gcntey." complete with windows, icons, menus, and mouse. These
ideas were adopted hy researchers dt Xerox PARC and incorporated
into machines they butlt. One day, Steve Johs, who co-invented the
Apple computer in his garage, visiied PARC, saw a GUI, ;ind tnstandy
realized its potential value, something Xerox management famously
did not (Smith and Alexander, 1988). Jobs then embarked on
building an Apple with a GUI This project led to the Lisa, which was
too expensive and failed commercially. Jobs' second attempt, the
Apple Macintosh, was a huge success, not only because it was much
cheaper than the l.isd. hut also because it was user friendly,
meaning that it was intended tor users who not only knew nothing
about computers but furthermore had absolutely no intention
whatsoever of learning. When Microsoft decided to build a
success!>i to MS-DOS, it was strongly influenced by the success, ot
Hie Macintosh It produced a GUI-based system called Windows,
which originally ran on l(ip of MS-DOS U.e . It was more like ;t shell
than a true Operating system) l;or aboi,t 10 years fn.m 1985 to t"J9\
Win- Windows was (us! a graplik at environment on top <>T MS-
DOS However, starting in 1995 a freestanding version ot Window's,
Windows 9<\ was released that incor- incorporated many operating
system tentmes into it. using the uudeilyinj! MS-DOS sys- system
only for booting and riiuriinu old MS-DOS programs lti 1098, a
sfigh'fly modified version of [his system, called Windows 98 w.i,
released Nevertheless, hotb Windows 05 and Windows 9$ stdl
contain ,i large amount ot 16-bit Iniel .(ssetnbly language Another
Microsolf oper.itint; svstcni is W'indovi.s NT i.NT stands for New
Technology), whtcb is compatible with WukWv. 9S -tf .t ceit.nn level,
bui a com- complete rewrite from Mraleb intetn.tlK If is ,t lull 12-fot
system The lead designer lor Windows N'l was D.tvid CuUci. who
w.ts Jlso one ol the designers oi the suit expected tliul the fir-,t
veisuiit oIN I would kill off MS-DOS and all other ver- versions of
Windows since it w;!S a v.istlv Mipcuor -^ysfcm, but it ti/^lcd Only
with Windows NT 4.0 did it Imally lJIlIi on m .i biLr «a\. especially on
coipor.Kc net- networks Version 5 of Wmdnws N I" was rcniifned
Windows 2(XIO in eJily l'>s»y. It was intended to be [he sineessi>i
tubnth Wiudi.v.-, 08 :ni(l Wmdows NT 4 (I. That Windows 98 called
Windows Me (Millennium edition) The other major contendei in trie
pcisoiul computer woild is UNIX (and us vanon*. denvdttves) I'NIX is
strongest oil woikstatums and other high-end com- computers, such
as network servers It is especially populai on machines [lowered hy

16 tNTRODUCTlON rHAP ' liigh-pertonnance RISC' chips. On

Peniiurn-based computers, Linux is becoming ,1 popular alternative
to Windows for students and increasingly many corporate iwrs. (As
an aside, throughout this bonk we will use ihe temi "Peniium" to
mean thu Pentium t, tt, 1!!. <md 4 ) Although many UNIX users,
especially experienced programmers, prefei a comnianJ-bdied m ten
ace to a GUI, nearl> all UNIX systems support a windowing system
called the- X Windows syMem produLed at M l.T This system
handles the basic window management, allowing users io create,
delete, move, and resize windows using a mouse Often a complete
GUI. such as Motif, is available io mn on top of the X Windows
system giving I'MX j look and reel something like ihc Macintosh or
Microsoft Windows, for those i'NIX users who want such a thing. An
interesting development thai began taking place during the mid-
1980s is the giowih of networks of personal computers nmtung
nelwork operaling sys- systems, and clislributed operating systems, i
lanenbaum and Van Stceti. 2002) In ,i network operating system,
the user-, arc aware of the existence ot multiple cm?i- putcis and
can log in to remote machines and copy files irom one mjilune to
another. Each machine runs its own local operating systeiii and has
its own local user (or User.s). Network operating systems are not
fundamentally different Irom single- processor operating sysiems
They obviously need a nctwmk interface controllci login and lemote
file access, but these addim.rj-. do not change the essential struc-
structure of the operating system A distributed operating .system, in
contrast, is oiic that appear* io its users as a traditional uniprocessor
system, even though it 1-. actually composed of mult tele-
teleprocessors. The users should not be aware ot where their
piograms are being run or where iheir files are located; that should
all be handled auiomaticall> anil effi- efficiently by the operating
system True distributed operating systems require mote than lust
adding a little cade to a uniprocessor operaiing system, because
distributed and centralized systems differ in critical ways. Distributed
systems lor example, often allow applications cessoi scheduling
algorithms in order t(> optimise ihe amount ot parallelism
Cormnunication delays within the netwuik often mean ihat these
(ai)d other) algorithms must run with incomplete, ouidated. or even
nicoirett information operating system has complete information
about ibe system state 1.2.5 Ontogeny Recapitulates Phytogeny Aftci
Charles Darwin's book Tin- Oimw of the Spet-ies was published, the
German 7oologT>,t Ernsi Haeckel siaied thar -Ontogcn>
Recapitulates Phylo- geny." By this he meant that the development
of an embryo (ontogeny) repeats

SEC. 1.2 HISTORY OFOPERATING SYSTEMS 17 (i.e recapitulates)

the evolution of the species (phylogeny). In oiher words, after
fertilization, a human egg goes through stages of being a. fish, a
pig, and so on before turning into a human baby. Modem biologisrs
regard this as a gross sim- simplification, but it still h.is a kernel of
truth in it. Something analogous has happened in the computer
industty. Each new species (mainframe, minicomputer, personal
computer, embedded computer, smart card, etc ) seems 10 go
through the development thaf its ancestors did. The first mainframes
were programmed entirely in assembly language. Even complex
programs, like compilers and operating systems, were written in
a.ssemhler. By the time minicomputers appeared on the scene.
FORTRAN, COBOL, and other high-level languages were common on
mainframes, but the new minicomputers were nevertheless
programmed tn assembler (for lack of memory) When micro-
microcomputers (early personal computers) were invented, they,
too, vvere programmed in assembler, even though by then
minicomputers were also programmed in high- level languages.
Palmtop computers also started with assembly code hut quickly
moved on to high-level languages (mi.stTy because the development
work was done on bigger machines). The same is true for smart
cards Now le u look per ng em Tl r m f m all had no protectio hard e
nd n ppo f 1 p g m n° he n imple operating hi handl d n m 11 1 d d [
oe m im Later they acqu red he h d e nd pe ns em pp h ndle m 1 pie
pro- programs at o ce nd h I II me h n o p b I When m n omp rs fi
ppe edh Ihdnpr nhd e and ran one m n 11> I ded p g m me n th gh
n 1 ip m ng was well establ hed n he fr m rid b hen G du 11 th q ed
pro- protection hdaredhb! n pog once The iirs-t microcomp we 1 p
ble f nn na il n p n t e, but later acq ed he b 1 J mlp can Pin p J mil
d it the Disk fr ppe el 1 g inf n e h m p m com- computers, and ond
heleEe v, ddnohehd disks, but with he dven ffl h ROM h 11 n h b q 1
f When disks first appeared, primitive file systems sprung up. On the
CDC 66(X), easily the most powerful mainframe in the World during
much of the 1960s, the file sys- system consisted of users having
the ability to create j file and then declare it to be permanent,
meaning it stayed on the disk even after the creating program exited
To access such a file later, a program had to attach >t with a special
command and give us password (supplied when the file was made
permanent). In eifeet, theri; was a single directory shared by all
users. 1( was up to the users to avoid file name conflicts. Early
minicomputer iile systems had a single directory shared by ;i!l users
and so did early microcomputer file system*, Virtual memory (the
ability to run programs larger than the physical memory) had a
similar development It first appeared in mainframes, minicomputers.

lH tIM'l RObt'(' IION t HAP 1 microcomputers and gradually worked

IK vvj> down to smaller and smaller sys- systems. Networking had a
similar history. In all cases, the software development was dictated
by the Technology The firs! microcomputers, lor example, had
sometliinji 'ike 4 KB of memory and no procecoon hardware. High-
level languagc-s ami multiprogramming were simply too much for
such a tiny system to handle. As the microcomputers evolved into
modem personal computers, they acquired the necessary hardware
and ihen the necessary software to handle more advanced featuies.
It is likely ihat this development will continue tor years to come.
Olher fields may also have this wheel of reincarnation, but in the
computer industry it seems to spin faster 1.3 THE OPERATING
SYSTEM ZOO All of this history and development has left iis with a
wide variety <>f operat- operating systems, not all ot which are
widely known in ihis section we will briefly touch upon seven ot them
We will come b.ick to some ot these different kinds of systems latei
in the book 1.3.1 Mainframe Operating Systems At the liigii und are
ihe operating systems l<ir the miiintraincs. those loom- sized
coinputeis still iouix.1 in major corporate daij centers These
computers dis- distinguish themselves from personal computer in
icinis oi Their i/O capacity \ mainframe with lfHO disks and
thousands .it gigabytes ot il.u.i is not iimisual. a personal computer
with these specifications vvonkl he odd indeed M.nntr.imcs are also
making something (if a comeback j*. liigli-cnd Woh seuers. scrvi-rs
for large-scale electronic eotiimcvee sites, and -crvers fm bnsiiiess-
to-business tiati- Tlie operating sjstems loi mainframes ,nc he.nili
oiieiucl tow.ud processing maiiyjobs.il once, mosi of which iieed
iiixxligums ai.iount' <ii I/O Thc> tvplc,ilfy otter Ibiee kinds of
seivi^es b.itcb. n.ins.Mion processing .inii tmicsbanng. ^> hatch
systeni is one tbut processes i out me jobs w iili()iil jiiv >nttir.icli vc
list i present Claims processing in an insurants L(iirip:m\ oi s.iies
icpottiiit! u,t .i chuiii of stores is tvpiciilly ddiic in batch mode
1i,inaction procVssinp %\stems fundfc large numheis ot small
rcqtie>K. fov e\,n!!j>if check processmg a! <l i>,mk or aii- lint.-
resen atidns. Eacfi unit of work is sm.ili. bill Ihe system miW handle
bi)ii- dreds or thousands per sei.oiid Tiincliuniiii s>stems allow
multiple vemme nscis lo runjohs on ihc computer at once, ^ncli a*1
^-K'CIn>nu j l^ii? djiahcise 1 hese luna- lunations are closely ielated
mainframe operating systems often perform all ol ibem A» example
niiiinframe operating system is OS/WO. a descendant of OS/J60

SEC M THE OPERATiWi SYSTEM ZOO IV 1.3.2 Server Operating

Systems One level down are the server operating systems They run
on servers, which ,ire either very large personal computers,
workstations or even mainframes. They serve multiple users, a<
once over a network and allow the users to share hardware and
software resource-,. Servers can provide print service, file service, or
Web service Internet providers run many server niaehmes to support
iheir customers and Web sites use servers to store the Web pages
and handle the incoming requests. Typical server opening systems
are UNIX and Windows 2000 Linux is alsd gaining ground for
servers. 1.3.3 Multiprocessor Operating Systems An increasingly
common way to get major-league computing power is to i_on- neet
multiple CPUs into a single system Depending on precisely how they
arc connected and what is shared, these systems aie called parallel
computers, mitlti- computers. or multiprocessors. They need special
(.peratnig systems, but often these are variations on the server
operating systems, wiih special features for communication and
connectivity 1.3.4 Personal Computer Operating Systems The next
category is the personal computer operating system. Their job is to
provide a good interface to a single user. They are widely used for
word process- processing, spread.sheets, and Internet access.
Common examples are Windows 98, Win- Windows 2000. the
Macintosh operating system, and Linux. Personal computer operating
systems are so widely known that probably little introduction is
needed, in fact, many people are nut even aware thai othei kinds
exist 1.3.5 Real-Time Operating Systems Another type of operating
system is the real-time system. These systems aie characterized by
having time as a key parameter Foi example, in industrtal proc-
process control systems, real-time computers have to collect data
about the production process and use it to control machines in the
factory. Often there dre hard dead- deadlines that must be met. For
example, if a car is moving down an assembly hue, certain actions
must take place at certain instant., of time If a welding robot welds
too early or too late, the car will be ruined If trie action absolutely
mmt occur at a certain moment (or wnhm a certain range), we li.ive
a hard real-time system. Another kind of real-time system is a soft
real-time system, in wtndi missing an occasional deadline is
acceptable. Digital audio or multimedia systems fall m this category.
VxWorks and QNX are well-known real-time operating systems.

20 1NTRODUC1 ION CHAP. I 1.3.6 Embedded Operating Systems

Continuing on down to smaller and smaller svstcms. w tonic to
patmt.p computers and embedded systems A palmtop computer or
PDA (Personal Digi- Digital Assistant) is a small computer that tits in
a ^hirt pocket and performs a sm.tll number of functions, ^ueli ;is
Jn electronic address book and memo p.itl bmbed- thouglit of as
computers nobilc t pbones These often h.Ke some characteristics ot
real-time systems but also have size, meinorv. and powci re si
fictions that m,ike tht'in special Examples of such opciJtiiic systems
are PalmOS and Windows Ch (Consumer Electronic). 1.3.7 Smart
Card Operating Systems The smallest operating systems run on
smart tards, which are credit card- si/.ed devices containing a CPU
chip. They have \ery severe processing powei and memory
constraints. Some of them can hitndle only a single function, such as
electronic payments, but others can handle multiple functions on the
same smart card. Often these are proprietary systems. Some smart
cards are Java oriented. What this means is that the ROM on the
smart card holds an interprets tor the Java Virtual Machine (JVM)
.lav.t applets (small programs) arc downloaded to the card an(l arc
interpreted by the JVM interpreter. Some of these cards can handle
multiple Java applets at the same time, leading to multiprogramming
and the need to schedule item Resource management and
protection also become an issue when two or more applets arc
present at the same time These issues ntust be handled by the
(usually extremely primitive) operating system present on the card.
1.4 COMPUTER HARDWARE REVIEW An operating system is
intimately tied U> the hardware oi the coinputei it runs on. It
extends the computer's instruction set and manages its resources To
work, it must know a great deal about lhc hardwaie. at least, about
how the hardware appears to the programmer Conceptually, a
simple personal computer can be abstracied to ;i model resembling
that of Fig |-5. The CPU. memory, and I/O devices are all connected
by a system bus and communicate with one another Ovci it Modern
personal computers haver a more complicated sCructure. involving
multiple buses, which we will look at later For the time being, this
model will be sufficient. In the follow- following sections, we wilt
briefly review these tomponenls and examine some of the hardware
issues that are t>f concern to operating system designers.

COMPUTER HARDWARE REVIEW Monitor g [sa Figure t-5. Some of

lhe components jj a simpiL' pcKonj] i-ompiiifj 1,4.1 Processors The
bnm of the computer is the CPU It fetches instructions, from
memory and executes them. The basic cycle of evciy CPU is, to fetch
ihe first instruction from memory, decode it to determine its type and
operands, execute it, and then tetch, decode, and execute
subsequent instinct ions, in this way, pmgrains are ear- earned ou!
Each CPU has, a specific set of instructions that it can execute Thus,
a Pen- Pentium cannot execute SPARC programs and a SPARC
cannot execute Pentium pro- programs. Because accessing memory
to get an instruction or data word takes much longer than executing
an instruction, all CPUs contain some registers inside to hold key
variables and temporary results Thus the instruction set generally
con- contains instructions to load a word from memory into a
register, and store a word from a register into memory. Other
instruclion.s combine two operands trom registers, memory, or boih
into a result, such as adding twu words and storing the result in a
register or in memory. In addition to the general registers used ti>
hold variables and temporary results, most computers have several
special registers that arc visible (o the pro- programmer. One of
these is the program counter, which contains the memory address ot
the next instruction (o be fetched. After (hat instruction has been
fetched, the program counter is updated to point to its successor
Another register is the stack pointer, which points to the top of the
current stack in memory. The stack contains one frame for each
procedure that ha.s been entered but not yet exited. A procedure's
stack frame holds those input parame- parameters, local variables,
and temporary variables that are not kept in registers. Yet another
register is the PSW (Program Status Word). This register con-
contains ihe condition code bits, which are set by comparison
instructions, the CPU priority, the mode (user or kernel), and various
other control bits. User programs

INTRODUCTION The PSW plays an important role in system calls

and I/O. The operating system must be awaie of all the registers
When time multi- multiplexing the CPU, the operating system will
often stop the running piogram tu (re)stait another one Every time it
stops a running program, the operating system must save all the
registers so the)? can be restored when the. program runs later To
improve performance, CPU (tesigneis have long abandoned ihe
.simple model of fetching, decoding, and executing one instruction
at a time. Many modern CPUs have facilities for executing more than
one instruction at the same time. For example, a CPU might have
separate fetch, decode, and execute units, so that while it was
executing instruction n, it cpuld also be decoding instruction ft + I
and fetching instruction n + 2 Such an organization is called a
pipeline and is illustrated in Fig |-6(a) for a pipeline with three
stages Longer pipelines are common fn most pipeline designs, owe
an (flsiruction has hcen fetched into the pipeline, it must he
executed, even if the pieceding instruction was a condi- conditional
branch that was taken. Pipelines cause compiler enters and
operating sys- system writers great headaches because ihe> expose
ihe uniiplcKifies of the underly- underlying machine to them Figure l-
fi 1,11 A ihnrc sljjie pipeline (b> A. ■4ipei'it.<i]ar (TD Even more
advanced ihan a pipeline design is a superscalar CPU. shown in Fig.
l-6(b) In this design multiple execution units are present, tor
example, one for integer arithmetic, one toi floating-point arithmetic,
and out fur Boolean operations. Two or more instructions are fetched
at once, decoded, and dumped into a holding buffer until (hey can
be execmed As so<m as an execution unit is tree, it looks in the
holding buffer to see if there is an instruction it con handle, and if
so, it removes the instruction trom the buffer and executes it An
implica- implication of this design is. that program instructions are
often executed out of order For the most part, it is up to the
hardware to make sure (he result produced is the same one a
sequential implementation would have produced, but an anni.yin^
amount o( ihe complexity is foisted onto the operating system, as
wo shall kee Most CPUs, except very .simple ones used in embedded
systems, have (wo nn,des, kernel mode and user mi.de, as
mentioned earlier. Usually a bit in the

sbC 14 COMPUTER HARDWARE RFV|EW 23 PSW controls the mode

When running in kernel mode, the CPU can execute every instruction
m its tnstruction set and use every feature of the hardware. The
operating system runs in kernel mode, giving it access to the
complete hardware In contrast, user programs run in user mode,
which permits only a subset of ihe instructions, to be executed and a
subset of the features to be accessed. Gen- Generally, all insiruciions
involving I/O and memory protection are disallowed in user mode.
Setting the PSW mode bit to kernel mode is also forbidden, or
course. To obtain services from the operating system, a user
program must make a system call, which tr;ips into the kernel and
invokes the operating system. The TRAP instruction swiiches from
user mode to kernel mode and starts ihe operaiing system. When
the work has been compieied. conirol is relumed to ihe user pro-
program a( the insiruciion following ihe system call. We will explain
the details of ihe sysiem call process later in this chapier. As a note
on typography, we will use ihe lower case Helvenca foni 10 indicate
sysiem calls in running text, like this read. li is worth noting ihai
compuiers have iraps other ihan the instruction for exe- cuiing a
sysiem call. Mosi of ihe oiher traps are caused by the hardware to
warn of ten exceptional siiuaiion such as an anempi to divide hy 0 or
a float mg~poin< underflow. In all cases the operaiing system gets
conirol and musi decide what to do. Someiimes ihe program musi be
lerminaied wcth an error. Oiher times, the error can be ignored (an
underflowed number can he sei to 0). Penally, when ibe program has
announced in advance thai it warns to handle ccnam kinds of condi-
conditions, conirol can be passed back 10 the program to let it deal
with ihe problem 1.4.2 Memory The second major component in any
computer is the memory ideally, a memory should be extremely fast
(faster tlian executing an oisiriicdon so ihe CPU is not held up by the
memoiy). abundanily large, and dirt cheap. No current (ccb- nology
satisfies all ot' ibese goals, so a different approach is uken. The
memory The lop layer consists of the rcg<s!cis infernal 10 the CPU
They are made ot ihe same maienal as the CPU and are ibus just as
tasl <<s the CPU. Consequently, (here is no delay in accessing tliem
The siotage capacity availahle ill them (s typ- typically 32 x 32-bits
on a 12-tm CPU and 64 x 64-bits on a 64-bh CPU i_es>, than I KB in
boih cases. Programs must manage the registers (i e . decide what
to keep in ihem) Ihemselves, in software. Next comes the cache
memory, which is mostly controlled by the hardware. Mam memory
is divided up into cache lines, (ypically 64 byies. w<tn addresses 0
10 63 in cache line 0. addresses 64 to 127 in cache line |. and so on.
The most heavily used cache lines are kept in a high-speed cache
located inside or veiv close io the- CPU. When the program needs <0
read a memory word, ihe cache hardware checks to see if the line
needed is in the cache. If it <s. ealled a cache

Marti rr Magne Magne emory cdisk ctape 64-512 MB 5-50 GB 20 100

GB e 1-7. A l> -i rouph Jf take requ tout 1 tin est is two ic pe ser
clo< nail it c ;k ivei the cycles Q iche hit. the tcquest bus to the maul
meiwin Cache Mis in Cache misses have to go (o memory, wi
memory is limited in size due to its high cost Some machines have
two or even ihrce levels ot cache, each one slower and bigger than
the one before it. Mam memory comes next This is the workhorse of
the racnion system Main memory is often called RAM (Random
Access Memory) Old timers sometimes call it core memory, hecause
computers in the 1950s and l%0s used tiny magnetizable territe
cores for main memory Currently, memories art; tens to hundreds of
megabytes and growing rapidly All CPU requests that cannot he
satisfied out of ilie cache go to main memory Next in the hierarchy is
magnetic disk (hard disk). Disk storage is two older? of magnitude
cheaper than RAM per hit and often iwo orders of magnitude largei
as well. The only problem is that ihe time to randomly access data
on it is close to three orders of magnitude slower This low speed is
due to the taci that a disk is a mechanical device, as shown m Fig. I
-8 A disk consists of one- or more metal platters that rotate at 541H.
7200. oi 10,800 ipm A mechanical arm pivots ovet [he platiers trom
the corner, similar to (he pickup arm on an old 33 rpin phonograph
for playing vinyl records !nform;t tion is written onto the disk in a
series ot concentric circles At any aiveti arm position, each of the
heads can read an aimulat region called a track. Together all ihe
tracks for a given arm position form a cylinder Each track is divided
into some number ot sectors, typically 512 bytes pel sector On
modern disks, the outer cylinders contain more sectors than ihe innci
ones. Moving the arm from one cylinder to the nexi one lakes aboui
1 msec Moving it to a random cylinder typically takes 5 msec io 10
msec, depending oi, the drive. Once the arm is on the correct irack.
the drive must wan foi the needed sector to rotate under the head,
an additional del,i> <>t 5 msec io 10 msec, depend- depending on
the drive's rpm. Once the sector is undei the head, reading or
writing occurs at a rate of 5 MB/sec on low-end disks io 160MB/sec
on taster ones.

COMPUTER HARDWARE REVIEW Read/write head I' per surface) in

of arm motion Tlie final layer in the memory hierarchy is magnetic
tape. This medium is often used as a backup for desk storage and
for holding very large data seis To access a tape, it must first be put
into a tape reader, either by a person or a robot (automated tape
handling is common at installations with huge databases). Then the
iapc may have 10 be spooled forwarded to got to the requested
block. All in all, this could lake minutes. The big plus of tape is that
tt is exceedingly che;ip per bit and removable, which is jmportani for
backup tapes that must be smred off-site in order to survive fires,
floods euthquakts etc The memory hierarchy we have discussed is
typical, but some installations do not have all the layers or have a
few different ones (such as optical disk). Still, in all ot them, as one
goes down the hierarchy, the random access nine increases
dramatically, the capacity increases equally dramatically, and the tost
per bit drops enormously. Consequently, it is likely that memory
hierarchies will be around for years to come. In addition to the kinds
of memory d^cussed ahove. many computers have a small amount
ot nonvolatile random aecess memory Unlike RAM, nonvolaiile
memory does not lose its contents when the power is switched off.
ROM (Read Only Memory) is programmed at the factory and cannot
be changed afterward. It is fast and inexpensive. On some
computers, tlie bootstrap loader used to siart the computer is
contained in ROM. Also, some I/O cards coine with ROM for han-
handling low-level device control. EEPROM (Electrically Erasable
ROM) and flash RAM are also nonvola- nonvolatile, but in contrast to
ROM can be erased and rewritten However, writing them takes
orders of magmiude more time than writing RAM. so ihcy are used in
the same way ROM is, only with the additional feature thai it is now
possible to correct bugs in programs they hold by rewriting them in
the field Yet another kind of memory is CMOS, which is volatile.
Many computers use CMOS memory to hold the current lime and
date. The CMOS memory and

26 iNTRODftriON < H\P I ihe cku-k cii-cuii ihai mcrcineuK the nine in
it arc pcw^u'Cl b-. a small bancry. *" ihe lime is correctly updaled,
even when ihc ,.mipul.-r i-- uHplu^cd. lhc CMOS installed bauery
often lasis for several years Hr>we\ei. whon it begins to Ian. Ilk'
compuier can appear to have Al/lieimer's disease. forger ring ihings
ihai u lia\ known for years, like which hard disk 10 booi from. Let us
now focus on main memory for a Inile while ]( is ohen desirahle to
hofd niuftipfe programs- m memory at once. If one program is
blocked waning W a disk read (o compfete, another program c;in
use ihe CPU. giving a henei CP1 • unfizaiion. However, with two or
more programs in main memory ai once, two prnbfems must be
so/vecf' 1 How to proteci ihe programs from i.ne .mother and ihe
kernel fmin ihem all. 2. How io handle refocation. Many solutions are
possible Howevei. all ol them, invoke ^juippijiL- ihe CTl' with special
hardware. The first probfem is obvious, but the second mie is a bti
nioic snhifi- W'Ueii ,i program is compifed and finked, the conipilci
,uid finku no nm kiicrtv v.hi-ri' in physical memory it will be loaded
when it is fveciitcd Kir tins reason ihc\ usu uHy assume it will stan at
address H. and jus] put ihc |i,si iDstruetinii ilk-iv Sup pose th.it the
first instruction Inches a HtiriHihin iKL-innr; a<ldtcss KUKKI Nov
suppose ih,it the enure program and dau jic huded sUrlma M jdcl.-
css Sft.lHfi). When the first instruction exei-irtes. it will l,ul bfiau^' ll
\wll rclcioiitf ri>e word at 10.000, liHc.td i.Mhu wi.id atM).<HXI F,,
s(Hu- i!iK piolik-1,1 we rti-t-d In fiiht'i tdocatc the progru,ti at !(Md
tune, hnduijr .ill nV aiklu-^s.- and i,todil>[i(g ihem The stniplfst
si,lutn,ii l^. -.hown in f-'tg. 1 >)u) in iH;> Hum- *c si\- j Li,n, puter
equipped wtth Iwirsjxxi.f! reijisiers, lhc hase regisier anJ H,i-Hniil
rvgi-U'r (Please note ib.it in t!ii> h,t..k, numhers be»innnij; with (K
air m hcxadcaiidil the C language conveimoii SiunlurK, iiiii(ibi-,> ]u-y,
(Hiitiy w.nil ,i k-iidui;! /,-it) ah in octal ) When a program is win, the
base lT.-istci is -.a h> fimi tn tlic st.in ill Us pto&ram it'Ktimd ihe l.nin
regi.sk-i tcHs how. Kugc tltc ^mib^nd pi(>gr,r,n it-\i .n,d data are
When an instruction u to be Ictchul, (h( hjulwarc checks [o \cf ,t llu
program Counter is less ih.rn flic limit legistur .md ,t n is jdcK il tu
thr \\t\p ic^is ter and sends tlie sum to intjnnn> ShinlsirK uln'it ihc
pnmr.ni' w.ints id Kt.-Ii . data wore! (e.g. from address 10,000). tbc
Wl^.uc .i.tiimuHCjIfv Akk th, tm, teiiis of the hase legislei (c y. .
50.000} to (ii.n dddicss arid st-nd- tlu- sum ih() (Kilt' to Ihe memory
The base legisler makes it impossible li.r ,r pu^rain tn leierciicc any
part i>r manory below if self Furthcnnoie the limit rcgi\tei nukes it
unpos

Sbc i 4 COMPUTER HARDWARE RL-VfLW sible to reference any p;>rl

ol"tnemor> abo*i' itst'i' Thus this scheme (he proiection and the
relocajion problem dt I he cos' at two new re^ slighj increase in
cycle liriK- (to perform (he limit check and addition). 27 > hc.lh y
User-2 data User-) data User program Operating System The check
<ind mapping result m, called a virtual address, n sical address. The
device lhat perfom MMU (Memory Management Unit). It bul is
logically between the CPU and the A more sophisticated MMU 15
iliu< MMU with two pairs ol base and limit re for the data. The
program counter and al pair I and data references use pair 2. As
multiple users share the same program w thing n<)t possihle with
the first seheme registers are set as indicated hy ih gram 2 is
running, they are set as ir Much more sophisticated MMUs e ing an
address generated hy the pn address used hy the memory, called a
phy- the check and mapping is called the s located 00 the CPU chip
or ek>se ti, it. ■atcd m Fig. ]-9<b). Here we have an isters, one lor
the program text and nno ;>ther references to thu program text jsc
Ldtisequenee. it is now possihle i<> have ii only (>rte cop> of K in
niemoiy. soine- When program I is running, ihe roar iwi to the leh of
Fig l-9(b) When pr<>- :cd by the arrows to the nght of the figure.
We will study some ot ihem later in Ihis

28 iNtKOOU TtON CHAP f honk The thing to note here is tii.it

m&iugme tile MML' must he ,m opeiatmg system itinction. since
useis cannot he trusted to do K correctly Twn aspects ot the memory
sysiem ii.Ke a maji.i effect rai performance
Fiist.eacheshidethe^.it.vdy slo* speed ul menuir.v When:, i.ogu.m
has bcii miming lur ,i w|iik-. (he cache is lull ol thai progrurn s cache
hues, giving good performance However, when the operating system
switches lrc,m one program to another, the cache returns lull <,i the
I'iist pro"tam's cache lines The ones needed Liy the new, progiam
must be loaded one at a time from phj.sudl memory This operation
can be a major pel form a nee hit ,i it happens too often Second,
when svwidung from one program to another, the MMU registers
have to be changed hi Fig ]-9(b). only four iegisters have to be-
reset, which is not a prol'lem, but in real MMUs, many more legists
h.ive to be reloaded either implicitly (,i- dynamically, as needed
Either way, it takes time The m,,ral of die storj is that switching trom
one program (o another, called a L-oniext swiieh. i<. an 1.4.3 I/O
Devices devices also interact heavily with the operatm? system As
we saw in Fi;; 1^, I/O devkus generally consist <if two parts, a
controller diid the device itsell The controller K a chip or a set of
chips i>n a plug-in hoard that phvsicarly controls the device, ft
accepts commands trom the operating system, for example, to rc;ur
dai;t froin the device, and carries them oui tn many cases, the actual
control of the device is \ery complicate^ and detailed, so it is the
J(,b of the controller to piehcnt a Mmplei interface @ the operating
system For example, a disk contiolier might accept a command to
read sector I 1.206 from disk 2 The controller then has <o convert
this linear sector number to a cylinder, sector, and head. This
u.nversiun may be complicaled by the tact that outer cylinders have
more sectors than inner ones and that Some had sectois have heen
remapped onto other ones Then the controller has td detenu me
which Cylinder the disk arm is on atid giVL- it a sequence or pulse.s
to move in o* out the requisite number of cylinders It has, to wait
until the proper sectoi has rotated under the head anrf then start
readtng and storing the bits a.s they c<,me olf the drive, removing
the preamble and computing the checksum 1-mally, it has to
assemhle the incoming bits into words and store them in memory To
d<> all this work, controllers often contain small embedded
computers that are programmed to do their work. The other piece is
the actual device itself Devices have tairlv simple inter- interfaces,
hoth hecause they c;tnnoi do much and io make them standaid The
latter is needed so that any IDF] disk controller can handle ,,n> IDE
disk, for example IDE stands for Integrated Drive Electronics and is
ihe standard type of disk on Penliums and some other computers
Since the actual dcv'ice interface is hidden

SEC I 4 COMPUTER HARDWARE REVIEW 29 hehind the controller, all

(hat the operJtmg system sees is the interface to the con- troHei
which may he quite dilterent from the interface to the device
Because each type of controller is different, different software is
needed to cont.oi each one. The software that talks to a controller,
giving it commands and accepting responses, is called a device
driver Each controller manufacturer has to supply a driver tor each
operating system it supports. Thus a scanner may come- witn
drivers tor Windows 98. Windows 2001), and UMX. for example. I'o
be umd, (he driver has to he put into the operating system so il can
ron in kernel mode. Theoretically, drivers can run outside (he kernel,
but tew current systems support this possibility because it requires
the ability to allow a user- space driver i0 be ahU- to access the
dev;ce in a controlled way, a feature rarely supported There art;
three ways the driver can he put into the kernel. The first way is to
relink the kernel with the new driver and then rehoot the system.
Many UNIX systems work like this,. The second way is to make an
entry in an operating system l'ile telling it that it needs the driver
and then reboot the system. At boot tune, the operating system
goes and finds the drivers it needs and loads them Windows works
this way. The Ihird way is tor the operating syslent to be ahle to
accept new drivers while running and install them on-Ihe-Hy wiihout
tlte need lo rebool. This way used to he rare btir is becoming mttch
more common now. Hot pluggable devices, such as USB and IBEh 1
W4 devices (discussed helow i always need dynamically loaded
drivers. rivery controller hus ii sniall number of registers tlial are
used to comniunicalc Wirh it For example, a minimal disk controller
might have registers for specify- specifying die disk address, memory
address, sector count, and direction (read or write) To activate the
controller, the driver gets a command from the operating system,
then translates it into the appropriate values to wrire inio (he device
regisrers. On some computers, the device registers are mapped into
the operating system's address space, so diey can be redd and
written like ordinary memory words. On such computers, no special
I/O instructions are needed and user pro- programs can be kept
away from the hardware by not pulling these memory ad- dre.s.ses
within their reach (e.g., by using hase and limit registers). On other
com- computers, the device registers are put in a special I/O port
space, with each register having a port address. ()n these machines,
special IN and OUT instructions are available in kernel mode to allow
drivers lo read and write the registers The former scheme eliminates
ihe need for special I/O instructions bul uses Up some of the address
space. The latter uses no address space but requires special instruc-
instructions Both systems are Widely u.sed. Input and output can be
done in three different ways In the simplest method, a user program
issues a system call, which the kernel then translates into a pro-
procedure call to ihe appropriate driver. The driver then .starts the
I/O and ■mis jn a iighi loop continuously polling the device to see if
il Ls done (usually there is some bit thai indicates ihat the device is
still busy). When ihe I/O has completed, ihe driver puts ihe daia
where ihey are needed (it any), and reiums. The operating

30 INTRODUCTION CHAP I syslem llien relum* control Io Ihc caller.

This method is called busy wailing and lias ihc disadvantage of lying
up ihe CPU periling ihe device until rt K finished (he second rnerhod
is for Ihc dnver ro start (he device and ask il ro give jn interrupt
when i( is finished- Ar lh.it poinl Ihe driver relume, fhe operating s\s-
lem ihen blocks rhe caller if need be and looks for (,mer work ro do
When the toirtrotler deiecls ihe end of (he transfer, it generates an
interrupt to signal com- completion hilcrnipls aie very importanl in
operalmp systems, so let us examine the idea closely In Fig. !-!O(aj
we see a ihrec-stcp process for I/O In step I. I hie ll ll h b d[ i Th
dnver tel troller tbe nu ciiip u accept ashcrK troller which y g g tarts
rbe deuce. When the compiler hat, linished reading or writing mber
or bytes it has been Sold to transfer, it signals the interrupt controller
sing certain bus lines in step 2 If ihe interrupt controller is prepared
to the interrupt (which it may not be if it is busy with a higher
priority one), ,i a pin on the CPU chip informing it m step 3 hi step 4,
the interrupt eo i- puts the number of the device on the bus so the
CPU can rcad it and know dev^e has just finished (many devices
may be ninnine at tlie same hme). 1 / Nexl ms 11 interrupt V 2.
Dispatch ~— Once the CPU has decided to take the interrupt, the
program counler and PSW are typically then pushed onto the curt
em stack and the CPU switched mti, kernel mode. The device
number may lie used as an index into part of memory t» find the
address of the interrupt handler for this device This pan oi' memory
)■> called the interrupt vector. Once the [ntenupt handler (part of
the driver for the interrupting device) has started, it removes the
stacked program counter and PSW finished, rt returns to the
previously-running user program to the first instruction that was not
yet executed. These steps are shown rn Fig l-10(b).

SEC t 4 COMPUTER HARDWARE REVIhW 31 The third method for

doing I/O makes use of a special DMA (Direct Memory Access) ch,P
that can control (he flow of biis between memory and some
controller without constant CPU intervention. The CPU sets up the
DMA chip, felling it how. many bytes 10 transfer, the device and
memory addresses 'involved, and the direction, and lets it go When
[he DMA chrp is done, it causes an mierrupt. which is handled as
described above. DMA and I/O hardware in general \vrll be
discussed in more detail in Chap. 5 Interrupt can often happen at
highly inconvenient moments, for example, while another imerrupt
handler is running For (his reason, (he CPU has a way to disable
interrupts and then reenable them later. While interrupts are
disabled, any devices that finish continue to assert their inttitrupi
srgnals, but ihe CPU is not interrop(ed until interrupts are enabled
again If multiple devices finish while in(errupts are d[.sabled. the
interrupt controller decides which one io le! through first, usually
based on static priorities assigned (o eiich device The highest prior-
priority device wins 1.4.4 Buses The organi?ation ot Fig. 1 -5 was
used ori minicomputers tor years and also on the original IBM PC.
However, as processors and memories got faster, iht ability ot a.
single bus (and certainly the IBM PC busi to handle all the traffic was
strained to the breaking point. Something h;td U. give. As a result,
additional buses were added, both for faster I/O devices and for CPU
to memon- traffic As a consequence of this evolution, a large
Pentium system currentK looks some- something itkeFig. 1-tl. This
system has eight buses (cache, local, memory. PCI, SCSI, USB. IDE.
and ISA), each with a different transfer rate and function. The
operating system must be aware of all of them for configuration and
management. The two main buses are the onginal IBM PC ISA
(Industry Standard Architecture) bus and its successor, the PCI
(Peripheral Component Interconnect) bus. The ISA bus. which was
originally the IBM PC/AT bus, runs at 8.33 MHz and can transfer 2
bytes ittonve, for a maximum speed of 16.67 MB/see. |t fs fnclitded
for backward compatibility with old and slow I/O cards. The PCI bus
was invented by Intel as a successor to the ISA bus. It can run at 66
MHi and tian<-fei & bytes at a irme, for a data rate of 528 MB/sec
Most high-speed I/O devices use the PCI bus now. Even some non-
Intel computers use the PCI bus due to the large number of I/O
cards available for tt. In this configuration, the CPU talks to the PCI
bridge chip over the local bus. and the PCI bridge chip talks to the
memory o\er it dedicated memory bus. often running at 100 MHz.
Pentium system, have a level-1 cache on chip Jnd a much larger
level-2 cache of( chip, connected to the CPU b> the cache bus In
addition, this system contains three specialized buses, IDE, USB. and
SCSI. The IDE bus is for attaching peripheral devices sueh ;is disks
and CD-

INTRODUCTION Ftffire 1-11. The si ROMs to the system. The IDE

bus ,s an outgrowth of the disk controller mUafan: on the PC/AT and
k now standard on nearly all Pentium-based systems for the hard
disk and often the CD-ROM. The USB (Universal Serial Bus) was
invented to attach all the slow I/O devices, such as [he keyboard
and mouse, to the computei It uses a small foui- wire connector, (wo
of winch supply electrical power to ihe USB devices USB is d
centralized bus in which a root device polls ihe I/O devices every 1
n.sec to see if they have any traffic It can handle an aggregate load
ot 1 5 MBZs.ec All the USB devices share a single USB device drivei,
making it unnecessary to install a new driver for each new USB
device Consequently, USB devices can be added to the computer
without the need to reboot The SCSI (Small Computer Svstem
Interface) bus rs a high-pcihwnianee bus intended for fast disks,
scanners, and other devices needing cnnsiderahlc bandwidth. It can
run at up to 160 MBZsec It hah been present on Macintosh sys-
systems since they were invented and is also popular on UNIX and
some Intel-based systems Yet another bus (not shown in Fig !-M) ,s
IEEE 1394. Some-times it i- called HireWirc, although sfnetly
Speaking, FireWiie is the name Apple uses foi its implementation of
1394. Like USB, IEEE 1394 is hit serial but is designed tot

SfcC 1.4 COMPUTER HARDWARE REVIEW 33 packet transfers at

speeds up to 50 MB/scc, making it useful for connecting digital
camcorders and similar multimedia devices to a computer. Unlike
USB, lEEb 1194 does not have a central controiier SCSI ami IEEE
1394 face competition from a faster version of USB being developed
To work in an environment such as that of Fig 1-1 I. the operating
system has 10 know what is out there and configure it. This
requirement led Intel and Micro- hoU to design a PC system called
plug and play, based on a similar concep< first implemented in the
Apple Macintosh. Before plug and play, each I/O card had a fixed
interrupt requesi level and fixed addres.ses for its I/O registers. For
example, the keyboard was interrupt 1 and used I/O addresses 0x60
to 0x64. the floppy disk controller was interrupt 6 and used I/O
addresses 0x3F0 to 0x31-7. and the printer was interrupt 7 and used
I/O addresses 0x378 to 0*37A, and so on. So far, so good- The
trouble came when the user bought a sound card and a modem card
and Roth happened to Use, say, interrupt 4. They would conflict and
would not work together. The solution was to include DIP switches
or jumpers on every I/O card and instruct the user to please set
them to select an interrupt levei and I/O device addresses that did
not conflict with any others in the usef's system. Teenagers who
devoted their lives to the intricacies of the PC hardware could
sometimes do this without making errors. Unfortunately, nobody else
could- lead- leading to chaos What plug and play does is have lhe
system automatically collect information about the I/O devices,
centrally assign interrupt levels and I/O addresses, and then tell
each card what its numbers are. Very briefly, that works j;> follows
on ihe Pentium. Every Pentium contains a parentboard (formerly
called a modierboard before political correctness hit ihe computer
industry). On the parentboard is a program called the system BIOS
(Basic Input Output System, The BIOS con- contains low-level I/O
software, including procedures to read the ke>board. write to the
screen, and do disk I/O, among other things. Nowadays, it is held in
a flash RAM, which is nonvolatile but which can be updated by the
operating sysiem when bugs are found in ihe BIOS When the
computer is booted, the BIOS is started. It first checks to see huw
much RAM is installed and whether the keyboard and other basic
devices are instaiied and responding correctly. It starts out by
scanning ibe ISA <ind PCI buses to detect all the devices attached to
them Some of ihese devices are typi- typically legacy (i.e., designed
before plug and play was invented) and have fixed interrupt levels
and I/O addresses (possibly set hy switches or jumpcis <>n the I/O
card, but not modifiable by the operating system) These devices are
recorded. The plug and play devices are also recorded If ihe devices
preseiil arc differenl from when the system was last booted, |hu new
devices are configured The BIOS then determines the boo! device by
trying a iist of devices stored in tlie CMOS memory. The user can
change ihis list by eniermg a BIOS configura- configuration program
just after booting. Typically, an ai tempt is made to b<,<,t from ihe
floppy disk. If that fails the CD-ROM is tried. If neither a floppy nor a
CD-ROM

;i par 34 iNrRODllTlON ('HAt* ' is preseni. the system is booted Horn

the iiaid disk The lust sector fiom the booi device is read into
memory and executed. Tlu.s sector contains a program that
normally examines ihe partition table ai ihe- end of the boot sector
to deiermine itKin is active Then a secondary hooi loader is icad in
fioin that parti- loader reads m ihe operating system from the active
partition and sl.tfts il The opciating system then queries, ihL- BIOS to
get the t tmiiguraticHi mforina- tioii For each device, n checks tu see
H 11 has tlie device driver. If noi. it asks, the usc-i to msert a floppy
disk or CD-ROM coniaming the dnver (supplied by tfie device's
manufacture^ Once ii has all the device drivers, ihe operating
sysiem |o;ids them into the kernel. Then it initializes its iable\.
creates whaievei baek- aiDinid processes are needed, and starts up a
login program or GUI on each leniu- iial. Ai least, ihis is the way it is
supposed (O v^ork In real lire, pluy and j>Ia> is frequently so
unreliable thai many people call it plug ,md pray. 1.5 OPERATING
SYSTEM CONCEPTS All operating systems have certain l.asic i.
(incepts such as proc-esses, memory, and files th;it are central to
understanding them. In the following seein>ns. we will look at some
of these basic concept;, ever so briefly, as an introduction We will
come back to each of them in great dclait Liter in this book, 'lo
illustraie these concept*, we will use examples from time to nine,
generally drawn from UNIX 1.5.1 Processes A key concept in all
operating sysiems is the- process. A process is basically a piogr.im in
execution Associated with each process is its address space, a fisi of
memory locations from some minimuiii (usually (n to some
maximum- whiLh the process can read and write The address space
contains the executable pro- program, the program's daia. anci its
stack. Also associated wuh each piwess is some set ot registers,
including the program counter, stuck pointer, and other hardware
registers, and all the other information needed to run the program
We will come hack to the process concept in much more deiail in
Chap 2. but f(»r the time being, the easiest way to get a good
intuitive feel for a process is 10 think about timesharing systems
Periodically, the operating system deudes, lo stop running one
process and start running another, for example, because tlie fust one
fun hid more truw its share of CPU time in the pasi seeond. When a
process is suspended temporarily like this, it mils' later be restarted
in exactly the same state it riad when it was stopped This means
tliat all information about the process must ix- explicitly saved
somewhere during [he suspension For example, the piocess may
have several files open for reading at once Associated

SfcO. OPERATING SYSIfcM CONCEPTS 35 with each ol these files is

a pointei giving tire current position A c . the number cif Ihc byte or
record to be iead next) When a process is temporarily suspended, all
these pointers must be s<ived so thai a read cull executed after (hi;
process is re- restarted will read the proper data. In many operating
systems, all the information about each proeess, other ihan the
contents of its own address space, is stored in an operating system
table called the process table, which is an array (or linked lis'1) of
structures, one t<ir each process currently m existence Thus,, a
^.suspended) process consists of its address space, usually called
the core image (in honor uf ihe magnetic core memories used in
days of yore), <ind its puieess1 table entry, which contains its
regisieis, among other things The key process management system
calls are those dealing with the oreancin and lermniatKin ot
processes. Consider a typical example A process oiled ihi: command
interpreter or shell read,, commands from a terminal. The user has
just typed a command requesting that a program be compiled The
shell must now create a new process that will run ihe compiler When
that pioeess has fin- finished the compilation, it executes a s\sttm L
ill to terminate itself. 1| a process can create one or more other
processes (referred to as child processes) and these processes in
tun) can create cliild processes, we t(inckly arrive at the process tiee
structure of Fig 1-12. Related processes that art? cooperating to get
some job d<,ne often need to communicate with one another and
synchrdnize their activities. This communication is called interprocess
com- communication, and will be addressed in detail in Chap. 1 ■e
1-12. A proixs : child priiu Other process system calls are availahle
unused memory), wait tor a child process tc .... with a different one.
Occasionally, there is a need to convey inf(,n is not sitting around
waiting for this information ■ating with another process on a differe
reqm mate, and ovei iory (or release lay its program ion to a running
process that iii example, a process thai is ,'omputer does so hy
sending messages to the remote process over a computer network
Other documents randomly have
different content
He heard the soft hum of the air-car behind him, turned and saw it
settling lightly to the clipped lawn. The remaining passengers were
moving toward it. Exarkos stood up and lifted his suitcase. Cudyk
turned back for one last look at the Quarter. It was full dark now,
and all he could see of it was the blocky, ambiguous outline of its
darkness against the glowing buildings beyond, and the cross-
hatched pattern of yellow street lights.
The lights went out.

[A] Pronounced "jung guo ren".

 *** END OF THE PROJECT GUTENBERG EBOOK THE EARTH
QUARTER ***

Updated editions will replace the previous one—the old editions will
be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States copyright in
these works, so the Foundation (and you!) can copy and distribute it
in the United States without permission and without paying
copyright royalties. Special rules, set forth in the General Terms of
Use part of this license, apply to copying and distributing Project
Gutenberg™ electronic works to protect the PROJECT GUTENBERG™
concept and trademark. Project Gutenberg is a registered trademark,
and may not be used if you charge for an eBook, except by following
the terms of the trademark license, including paying royalties for use
of the Project Gutenberg trademark. If you do not charge anything
for copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such as
creation of derivative works, reports, performances and research.
Project Gutenberg eBooks may be modified and printed and given
away—you may do practically ANYTHING in the United States with
eBooks not protected by U.S. copyright law. Redistribution is subject
to the trademark license, especially commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the free

distribution of electronic works, by using or distributing this work (or
any other work associated in any way with the phrase “Project
Gutenberg”), you agree to comply with all the terms of the Full
Project Gutenberg™ License available with this file or online at
www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand, agree
to and accept all the terms of this license and intellectual property
(trademark/copyright) agreement. If you do not agree to abide by all
the terms of this agreement, you must cease using and return or
destroy all copies of Project Gutenberg™ electronic works in your
possession. If you paid a fee for obtaining a copy of or access to a
Project Gutenberg™ electronic work and you do not agree to be
bound by the terms of this agreement, you may obtain a refund
from the person or entity to whom you paid the fee as set forth in
paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only be

used on or associated in any way with an electronic work by people
who agree to be bound by the terms of this agreement. There are a
few things that you can do with most Project Gutenberg™ electronic
works even without complying with the full terms of this agreement.
See paragraph 1.C below. There are a lot of things you can do with
Project Gutenberg™ electronic works if you follow the terms of this
agreement and help preserve free future access to Project
Gutenberg™ electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright law
in the United States and you are located in the United States, we do
not claim a right to prevent you from copying, distributing,
performing, displaying or creating derivative works based on the
work as long as all references to Project Gutenberg are removed. Of
course, we hope that you will support the Project Gutenberg™
mission of promoting free access to electronic works by freely
sharing Project Gutenberg™ works in compliance with the terms of
this agreement for keeping the Project Gutenberg™ name associated
with the work. You can easily comply with the terms of this
agreement by keeping this work in the same format with its attached
full Project Gutenberg™ License when you share it without charge
with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside the
United States, check the laws of your country in addition to the
terms of this agreement before downloading, copying, displaying,
performing, distributing or creating derivative works based on this
work or any other Project Gutenberg™ work. The Foundation makes
no representations concerning the copyright status of any work in
any country other than the United States.

1.E. Unless you have removed all references to Project Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project Gutenberg™
work (any work on which the phrase “Project Gutenberg” appears,
or with which the phrase “Project Gutenberg” is associated) is
accessed, displayed, performed, viewed, copied or distributed:
 This eBook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this eBook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is derived

from texts not protected by U.S. copyright law (does not contain a
notice indicating that it is posted with permission of the copyright
holder), the work can be copied and distributed to anyone in the
United States without paying any fees or charges. If you are
redistributing or providing access to a work with the phrase “Project
Gutenberg” associated with or appearing on the work, you must
comply either with the requirements of paragraphs 1.E.1 through
1.E.7 or obtain permission for the use of the work and the Project
Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is posted

with the permission of the copyright holder, your use and distribution
must comply with both paragraphs 1.E.1 through 1.E.7 and any
additional terms imposed by the copyright holder. Additional terms
will be linked to the Project Gutenberg™ License for all works posted
with the permission of the copyright holder found at the beginning
of this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files containing a
part of this work or any other work associated with Project
Gutenberg™.

1.E.5. Do not copy, display, perform, distribute or redistribute this

electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the Project
Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if you
provide access to or distribute copies of a Project Gutenberg™ work
in a format other than “Plain Vanilla ASCII” or other format used in
the official version posted on the official Project Gutenberg™ website
(www.gutenberg.org), you must, at no additional cost, fee or
expense to the user, provide a copy, a means of exporting a copy, or
a means of obtaining a copy upon request, of the work in its original
“Plain Vanilla ASCII” or other form. Any alternate format must
include the full Project Gutenberg™ License as specified in
paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,

performing, copying or distributing any Project Gutenberg™ works
unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or providing

access to or distributing Project Gutenberg™ electronic works
provided that:

• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
 about donations to the Project Gutenberg Literary Archive
Foundation.”

• You provide a full refund of any money paid by a user who

notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of

any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™

electronic work or group of works on different terms than are set
forth in this agreement, you must obtain permission in writing from
the Project Gutenberg Literary Archive Foundation, the manager of
the Project Gutenberg™ trademark. Contact the Foundation as set
forth in Section 3 below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend

considerable effort to identify, do copyright research on, transcribe
and proofread works not protected by U.S. copyright law in creating
the Project Gutenberg™ collection. Despite these efforts, Project
Gutenberg™ electronic works, and the medium on which they may
be stored, may contain “Defects,” such as, but not limited to,
incomplete, inaccurate or corrupt data, transcription errors, a
copyright or other intellectual property infringement, a defective or
damaged disk or other medium, a computer virus, or computer
codes that damage or cannot be read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for

the “Right of Replacement or Refund” described in paragraph 1.F.3,
the Project Gutenberg Literary Archive Foundation, the owner of the
Project Gutenberg™ trademark, and any other party distributing a
Project Gutenberg™ electronic work under this agreement, disclaim
all liability to you for damages, costs and expenses, including legal
fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR
NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR
BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH
1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK
OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL
NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF
YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of receiving
it, you can receive a refund of the money (if any) you paid for it by
sending a written explanation to the person you received the work
from. If you received the work on a physical medium, you must
return the medium with your written explanation. The person or
entity that provided you with the defective work may elect to provide
a replacement copy in lieu of a refund. If you received the work
electronically, the person or entity providing it to you may choose to
give you a second opportunity to receive the work electronically in
lieu of a refund. If the second copy is also defective, you may
demand a refund in writing without further opportunities to fix the
problem.

1.F.4. Except for the limited right of replacement or refund set forth
in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO
OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of damages.
If any disclaimer or limitation set forth in this agreement violates the
law of the state applicable to this agreement, the agreement shall be
interpreted to make the maximum disclaimer or limitation permitted
by the applicable state law. The invalidity or unenforceability of any
provision of this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation,

the trademark owner, any agent or employee of the Foundation,
anyone providing copies of Project Gutenberg™ electronic works in
accordance with this agreement, and any volunteers associated with
the production, promotion and distribution of Project Gutenberg™
electronic works, harmless from all liability, costs and expenses,
including legal fees, that arise directly or indirectly from any of the
following which you do or cause to occur: (a) distribution of this or
any Project Gutenberg™ work, (b) alteration, modification, or
additions or deletions to any Project Gutenberg™ work, and (c) any
Defect you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new computers.
It exists because of the efforts of hundreds of volunteers and
donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project Gutenberg™’s
goals and ensuring that the Project Gutenberg™ collection will
remain freely available for generations to come. In 2001, the Project
Gutenberg Literary Archive Foundation was created to provide a
secure and permanent future for Project Gutenberg™ and future
generations. To learn more about the Project Gutenberg Literary
Archive Foundation and how your efforts and donations can help,
see Sections 3 and 4 and the Foundation information page at
www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-profit
501(c)(3) educational corporation organized under the laws of the
state of Mississippi and granted tax exempt status by the Internal
Revenue Service. The Foundation’s EIN or federal tax identification
number is 64-6221541. Contributions to the Project Gutenberg
Literary Archive Foundation are tax deductible to the full extent
permitted by U.S. federal laws and your state’s laws.

The Foundation’s business office is located at 809 North 1500 West,

Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up
to date contact information can be found at the Foundation’s website
and official page at www.gutenberg.org/contact

Section 4. Information about Donations to

the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission of
increasing the number of public domain and licensed works that can
be freely distributed in machine-readable form accessible by the
widest array of equipment including outdated equipment. Many
small donations ($1 to $5,000) are particularly important to
maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws regulating

charities and charitable donations in all 50 states of the United
States. Compliance requirements are not uniform and it takes a
considerable effort, much paperwork and many fees to meet and
keep up with these requirements. We do not solicit donations in
locations where we have not received written confirmation of
compliance. To SEND DONATIONS or determine the status of
compliance for any particular state visit www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states where

we have not met the solicitation requirements, we know of no
prohibition against accepting unsolicited donations from donors in
such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot make

any statements concerning tax treatment of donations received from
outside the United States. U.S. laws alone swamp our small staff.

Please check the Project Gutenberg web pages for current donation
methods and addresses. Donations are accepted in a number of
other ways including checks, online payments and credit card
donations. To donate, please visit: www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could be
freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose network of
volunteer support.
Project Gutenberg™ eBooks are often created from several printed
editions, all of which are confirmed as not protected by copyright in
the U.S. unless a copyright notice is included. Thus, we do not
necessarily keep eBooks in compliance with any particular paper
edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg Literary
Archive Foundation, how to help produce our new eBooks, and how
to subscribe to our email newsletter to hear about new eBooks.
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookball.com