![xvi CONTENTS
17.2.2 Major Data Structures... 2» « SPM Sl BRO A 405
17.3 .Name.Spadege. talwdiwis ss + 0 cums » » SONS POPS ey 8G 406
17.8.1 Drive Specifies: jis «2s. « « I ees ee 407
17.2.2. Account. Specifiers...... Weevwes snes & AGES CMI. atee 2 8 408
17.3.8. Hlierarchical. Naming «0.0.» G2¥7) S°QNS @ RINIITET. smear « a a 409
17.8.4..File Extensions... «ss 0 00 +t 2 0 pl)Weeer eterere Gree. One 410
17.3.5.,File Versions . mUawue 2?nwoteelet
acta Lee « . 41]
17.3.6 Special Files and Directories 2. ib. 6 ee
ee we ee 411
17.3.7 Relative and Absolute Names... .. . .)MWIN bee ee Be 412
17.4. Managing Storage Spacteaswiew og, 47.1. BRI, che cm 412
17.4.1)..File System Mebaiate wre una’ 3 ne BIG, LBs « 412
17.4.2. Data Unite. werd). ernie. ae leer, ee oe 413
174.3. FreaSpace Management. ...:1..2<s.2
4s VINE. Oa 413
17.4.4. Regular Piles disiy Yxted ees 2 8 es oe , Sa 415
A ee POUTORRE ORE 6 css. 22a 8 9k tee ern Bae ea 418
Wek BORKes vecnce sieen xan 6 Reecarnigds # Sundaes 2° Ue eee ae ee ae 418
Lite WDivectiries sas 4.28.5 ut + v.55 os ee eae 419
DY > 1A aseties. totus, SO ee Fee ene Ee ee a ee 419
1s ~GonsistenomC necking: 3.< 7 %-+ 9.2 9 4s. €ohn ee ee ae ee 420
17.6 Journaling and Log-Structured File Systems................ 421
1%.% (Block Gaching * 02 :.g eho ee te, Ee Behe gees eS EN 422
17.82 >Simmeryicceset sk8 ek Se See ee ee ee ee ee gs een. 423
17.0. *Begercises ys 609 6g 3 OE bk ee oe ee ae, Ces aed 424
18 Some Examples of File Systems 425
18.1. QTSS. 75. 2os.s..6 5 OMe Ope 4 a) ani CRA: sf 425
18.1.1. First: CIss File Systemearws) you 4 ¢ eta.
-<Lae 2s. 425
18:1.2.. Second CTSs. File System. Doanaau)
sit yirss sees 5 426
18.2 ¢Multics (2 Pe. Ss 2st Bes et oak walk sactsaeerrt ses 427
18.9 RIA. 26. tin ai os 2 SO Pe gourmet 1A 428
18.4 .Sixth Edition UNIX) ; «. « « speneeiekaged)
ss palbegil 8 oo. 429
18.5 -4:3BSD. ». <a 5 os >» SRR eee aly Sale, CAE 431
TOG VINES hes at aie Ge ae ow ke NMS Rn asnt
le pa aT a 432
18.7 .Windows NICS. gh ss sky WM BS eS 2 434
TRS Summary) Pao eed ek oo Re ee eo ee 435
18.9 Exercises . 2 ii 4 6 ees Sec cae ey OS eee 435
19 File Systems in Inferno 437
19.1 -The-Role of FileServera ...... <..0. RA 437
lOcisle eTheiStyx Protocol, ... .i.¢ - ae ei Bee 438
19.1.2. Built-in Kernel File Servers... « «.8ishewb
LT). 2 441
19.1.3, User-Space File,Servers.... 20 egies
0. .. 44]
19.2. The Root.Device Server; « .« .« < ... Spiel weeieve SE Teeeeets 5 442
19,2.) Providing the Names. Servedyater® oif4.5:14 Iooe. J LESS oe 443](https://image.slidesharecdn.com/27572540-250516052201-3f76a3cd/85/Principles-Of-Operating-Systems-Design-And-Applications-1st-Edition-Brian-L-Stuart-24-320.jpg)
![CONTENTS xvii
19.2.2. Walking the Root Server’s Tree . 00.0.0.) ue. 8 444
19.2.3, Reading from the RootSérvers. wil eis gaulummen.
.. .. 445
19.3 Generic Styx. Meceage Handler edwill!.:.ncihulodsgowbantl.
.Qn08. .. 445
Mi) Greatinewirectory.Potry..........:. wae. Te 446
UP5.2. Apomerekiogg Nemee on. ice i ee ee ee. 2 446
tc “Wereeeeeireetnry Tregiviks 6. ee es 447
19.4 Mative Infertio FileSysten «oui .oote.2 uelteiag?.
w eolaival: 450
iA Teeth i. c e . SORA
al 451
WAZ Maimwerver.Process ..chwiwead
busrgime Lowell. KIS... 456
1943. Proceating a: StyaRequestt acideal dduewtiews). 2.18... 456
T2a8 Wales Directory Tree... .. 1... - Sieeida. fhe... 458
45. Steshing a Directory sisi casos mela). 218... 460
ISAC Rees irom b.Pile . y+ ahricwanetl cad Feat. Alf « . 464
19.4.7. On-Digk Date Structures a ijax todas. obtoanglkl
.DellG< :« 466
WAS, Keading 6 Directory Entry ....» aaixwer
avoresh cual. 21 471
EAD ee INS BO oe To yo apne to beste obec lR eo A471
1.4.10. eating MileBlock ... -ccun ign S403 ageanaieds ote tes < 472
P41 Procedeign Ieitirect Blocks... . i camagecheisnealle
sit (So +@ A474
19.4.13..Petching from the Buffer Cache) ..)sicisp8)
nh SO hoki @>« - 475
See CIN Sg ia go homed ie SA eo or ee ieee VRMOIO ie AT7
EG eae ee ee eek eee 478
20 File Systems in Linux 479
le URINE, RR Se es te Le idyit hs eget Mahe pe 8% 479
ee SpE eo aS a a PN 480
Se PACA eI ae foso ge aes aah Oo oh ag adres 480
ee TOS ee Fe Hoag ne oe A Oe 2 8 ey 481
TE I eo ee se Se os ee ee ee OS 481
es Ele ER Po ee oe ee ee ge ee eee 481
PT ee aee EC te Se Ate hp eae gape se sage ee 482
Tae ee OC. ve on aeede ae ee ee ae ne 482
ME ase 2 cE Pee en ee ee 485
eee ne cen Emivien 520 255.5 2 ee a eee es 487
ee eee ee ERS Be. Sc tee sk PP SS ee eee ee ee ek 488
ro cede os AR a Ni ae a a ie ht al 488
90.42" “Genente Directory Lookup'(Part'T): 2. 2°. 9OPE4 Oe. , 494
304-4. “Generic Directory Lookup (Part 2) ¢.5. 6 6 oe o 495
Nye oats Wrectory Lookup? «Pete?
OU Pe, ee 496
Saw Haste wirecory search . Cer! Pe, lites 498
A Lok o Directory Block-Searche se. 8!Ste BANOS.eed 501
Gy Mike VOR TEE oe ee it ewe so 3 OU BO sb 502
205k. Lanux Write Systema Wall on wk ee PU A UIOOE . ed 502
6. Cenene File, Witting 4.4 6s as ye so oe OR. Bd 503
RAI NVR: lee otfe hoe ok oe AO ee AL] 505](https://image.slidesharecdn.com/27572540-250516052201-3f76a3cd/85/Principles-Of-Operating-Systems-Design-And-Applications-1st-Edition-Brian-L-Stuart-25-320.jpg)
![—
fs
Pic
os
Webi
ity
The>
ey
ny
hie
Lep
aoe
ey
ee
vw
Li
abe
Abs.
ivy.
ta
ar
ten
>.
LJ
ees
te
ee ee
on =
| we
— “te ’ ia
, ° x ° ree : i ae 7
ee eee
rn eeee rao:
7 > A io me on 608
"aes . « 7 =i
tb be A AD
2 One
20m oly ot ier -
ne : P ‘ bon me)
a 1906 © S45 ONS : spo ee? ’
» Cee ta eh
aa | |
@arverse Sere! A
. = 6. a .
“ - (ae Oe D4
~~» Gir oe :
. , — Os
> = oq Li >
i
=
‘ ac aula
2 . =
7 : :
+
e e
=
ip
i] a
.
at
a
6
— , as
7
a
_
~;
a](https://image.slidesharecdn.com/27572540-250516052201-3f76a3cd/85/Principles-Of-Operating-Systems-Design-And-Applications-1st-Edition-Brian-L-Stuart-28-320.jpg)
![10 CHAPTER 1 INTRODUCTION TO OPERATING SYSTEMS
machine so that debugging time did not prevent the machine from doing useful work for
other users.
Even today, this type of noninteractive operation makes sense in some areas. Examples
include periodic running of payroll, billing, group membership mailings, and so forth. The
basic idea is that a user submits a job to the system and then comes back later to get the
results. Groups of jobs are collected together in batches and each job is run to completion
before moving on to the next. In some of the early batch systems, jobs were submitted as
a deck of punched cards handed over to an operator in the computing center or perhaps
fed into a card reader by the user. In more modern applications of the technique, jobs
might be submitted from some form of interactive session, but still run as part of a batch.
Operating systems that operate in this way are called batch operating systems.
In some installations, groups of jobs are collected on a smal] computer and put onto tape
to be processed by the main computer. In these cases, it is also common for the output
from the main computer to be written to a tape, which is then read by another smaller
computer that prints the results. These printed outputs are then placed into output bins
for users to pick up.
By developing these batch operating systems, developers began to break the one user/one
program/one computer triangle. The one user leg is broken here. Even though at any
point in time, the computer is working on behalf of only one user, many users can be in
the process of using the overall computing facility.
1.3.3. Time-Sharing Operating Systems
As usual, we don’t get something for nothing. Batch operating systems make using
the computer more efficient in the sense that the CPU does useful work for a greater
percentage of the time. However, this benefit comes at a cost. When people work directly
with a computer, there is an interactive component that gives an immediacy making one’s
debugging time more effective. Even though we take this as self-evident today, the benefit
of interactive use was not seen as worth the cost of less-efficient CPU usage in most early
environments.
Nevertheless, there were some environments that did hold to manual scheduling of com-
puter time. In these environments (often research), another phenomenon soon emerged.
A programmer who had signed up for an hour but ran into a snag would often leave
the system before the hour was up. Something of a subculture developed where other
members of the computing community waited around for those times when the computer
would be free for part of a scheduled hour.
As the decade of the 1960s dawned, some of the researchers in these environments
noticed that the computer turned out to be more efficiently used when scheduling and
turn-taking took place with more fine-grained resolution. The natural thing to do with
an observation like this is to ask what happens if we take it to the limit. In effect, we ask
what would happen if we moved from one user’s program to another with an infinitesimal
time between these switches? Two things immediately emerge from this question. First,
it becomes clear that a program cannot run to completion before switching to another.
Second, we see that users could not alternate the use of a single I/O device to communicate
with the system. However, if we could solve these issues, we’d have a system where](https://image.slidesharecdn.com/27572540-250516052201-3f76a3cd/85/Principles-Of-Operating-Systems-Design-And-Applications-1st-Edition-Brian-L-Stuart-46-320.jpg)
Principles Of Operating Systems Design And Applications 1st Edition Brian L Stuart
- 1. Principles Of Operating Systems Design And Applications 1st Edition Brian L Stuart download https://ebookbell.com/product/principles-of-operating-systems- design-and-applications-1st-edition-brian-l-stuart-55145080 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Basic Principles Of An Operating System Learn The Internals And Design Principles Dr Priyanka Rathee https://ebookbell.com/product/basic-principles-of-an-operating-system- learn-the-internals-and-design-principles-dr-priyanka-rathee-12206632 The Art Of Linux Kernel Design Illustrating The Operating System Design Principle And Implementation Dazhao https://ebookbell.com/product/the-art-of-linux-kernel-design- illustrating-the-operating-system-design-principle-and-implementation- dazhao-21354456 Public Transportation Systems Basic Principles Of System Design Operations Planning And Realtime Control Carlos F Daganzo https://ebookbell.com/product/public-transportation-systems-basic- principles-of-system-design-operations-planning-and-realtime-control- carlos-f-daganzo-42685326 Public Transportation System Basic Principles Of System Design Operations Planning And Realtime Control Carlos F Daganzo https://ebookbell.com/product/public-transportation-system-basic- principles-of-system-design-operations-planning-and-realtime-control- carlos-f-daganzo-37467866
- 3. Principles Of Operating Systems Naresh Chauhan https://ebookbell.com/product/principles-of-operating-systems-naresh- chauhan-36384238 Principles Of Modern Operating Systems 2nd Jose M Garrido Richard Schlesinger https://ebookbell.com/product/principles-of-modern-operating- systems-2nd-jose-m-garrido-richard-schlesinger-4727430 Brains As Engines Of Association An Operating Principle For Nervous Systems Hardcover Dale Purves https://ebookbell.com/product/brains-as-engines-of-association-an- operating-principle-for-nervous-systems-hardcover-dale-purves-10128752 Operators Guide To General Purpose Steam Turbines An Overview Of Operating Principles Construction Best Practices And Troubleshooting Robert X Perez David W Lawhon https://ebookbell.com/product/operators-guide-to-general-purpose- steam-turbines-an-overview-of-operating-principles-construction-best- practices-and-troubleshooting-robert-x-perez-david-w-lawhon-56349040 Magneticallycontrolled Shunt Reactors Historical Overview Operating Principles Computer Simulation And Return Of Experience Ga Evdokunin https://ebookbell.com/product/magneticallycontrolled-shunt-reactors- historical-overview-operating-principles-computer-simulation-and- return-of-experience-ga-evdokunin-50252346
- 5. PRINCIPLES:-OF OPERATING SYSTEMS | = TT . design + applications
- 6. orn A gz ... [pulled an all-nighter to finish my final project for a Game Development class. It finished compiling one minute before the class started and | had to rush to campus just to find out that the Al in the game caused a major crash and we had to revert to a previous build for the final presentation. Learn multiple programming languages. Your school might focus on one or two languages like C++ or Java, but make sure to learn more. At Microsoft, | use up to eight different languages at a time, and at home| use others. Your programming language toolbox should at least include: a general-purpose Object Oriented/Pro- cedural language like C++ or Java; a scripting language like Perl, PHP, or Ruby; and a markup language like XHTML. And don’t wait for a class to teach you a language —get a book or use the net. a Tim Berners Lee, the man who invented the World Wide Web. Berners-Lee still oversees the W3C and makes lots of decisions relating to web standards. I’d love to discuss where he sees the internet in 10 years and beyond. In 10 years, |think I’ll still be working at Microsoft—likely as a lead or manager. My main goals are to be a millionaire by the age of forty, and to make a difference in the Computer Science industry before | die. Well, I’d also like to walk into a room with an orchestra following me playing the Darth Vader theme, but that’s just for fun. | read stories linked from digg.com almost every day. | usually get the best pick of technology news that way. |also subscribe to a number of Mac news feeds to see what Apple is going to come up with next.
- 8. Digitized by the Internet Archive in 2022 with funding from Kahle/Austin Foundation https://archive.org/details/principlesofoperO000stua
- 9. Principles of Operating Systems: Design & Applications Brian L. Stuart FedEx Labs University of Memphis Australia - Canada - Mexico - Singapore - Spain - United Kingdom - United States
- 10. Principles of Operating Systems: Design & Applications Brian L. Stuart Senior Product Manager: Marketing Manager: Cover Design: Alyssa Pratt Bryant Chrzan Yvo Riezebos Designs Acquisitions Editor: Editorial Assistant: Art Director: Amy Jollymore Patrick Frank Beth Paquin Development Editor: Manufacturing Coordinator: Compositor: Jim Markham Julio Esperas Brian L. Stuart Content Project Manager: Printer: Matt Hutchinson RR Donnelley, Crawfordsville COPYRIGHT ©2009 Course Technology, a division of Thomson Learning, Inc. Thomson Learning’ is a trademark used herein under license. Printed in the United States of America For more information, contact Course Technology, 25 Thomson Place, Boston, Massachusetts, 02210. Or find us on the World Wide Web at: www.course.com ALL RIGHTS RESERVED. No part of this work covered by the copyright herein may be reproduced or used in any form or by any means—graphic, electronic, or mechanical, including photocopying, recording, taping, Web distribution, or information storage and retrieval systems—without the written permission of the publisher. For permission to use material from this text or product, submit a request online at http://www.thomsonrights.com. Any additional questions about permission can be submitted by email to thomsonrights@thomson.com. Disclaimer Course Technology reserves the right to revise this publication and make changes from time to time in its content without notice. ISBN 1-4188-3769-5
- 11. | ien f Oparsttag Syste re Sepeetars coed Loleialtert iin ‘Bares Saectue viet Tesibpadactcet bere Princip: af Me ress Managemen: a tecrwe Rcatritee of Py sccer Nt Amageemenn AF. Promes Va wn — 2 Pee Process Menearede mw ww hoc ; a=, — a i ties n/ Mere icy se! pom we BO Soa Manencltaal Mo. + ° 16. s.yg- aemyt! As Memmity Mauageriers tn feto1 — . Pad Migwiccy Moangerrrent ti ii: _ y ae Petat gies of! 1) 1) Device at ry Pars oe A Erapice f3iQ Diewlew NW’ (Lager) , OC).Devices iy ligerac ne ; Devices in Licws _ a 44 wpriples oF File tiyrtcm= < ome Frampton at Pile Syren —~ - ria _ S axt a}
- 12. ee Pye> Soe , tage oss C-a— 7 an ae near Gawtiiegew. os ; ~S tou wee y ‘. : Tagan fee “Goade : em ie) ey, - OP 1 OQit ys y ees om - Pits : bl 7
- 13. Brief Contents 8 9 Preface Introduction to Operating Systems Some Example Operating Systems Inferno Structure and Initialization Linux Structure and Initialization Principles of Process Management Some Examples of Process Management Process Management in Inferno Process Management in Linux Principles of Memory Management 10 Some Examples of Memory Management 11 Memory Management in Inferno 12 Memory Management in Linux 13 Principles of I/O Device Management 14 Some Examples of I/O Device Management 15 I/O Devices in Inferno 16 I/O Devices in Linux 17 Principles of File Systems 18 Some Examples of File Systems 19 File Systems in Inferno Xxi 121 141 165 195 233 253 281 307 333 345 371 399 425 437
- 14. vl 20 File Systems in Linux 21 Principles of Operating System Security 22 Principles of Distributed Systems A Compiling Hosted Inferno B Compiling Native Inferno Suggested Readings Index BRIEF CONTENTS 479 511 569
- 15. Contents LJ 1.2 1.3 1.4 1.5 1.6 Let 1.8 2 Some Dall Preface xi 1 Introduction to Operating Systems | Woatiean Onpersting System? ....... .ele's ames . £A8. =>; | Bank a DART a se a bed oe wg IES OR, Zz Rilie ) Derviee Providers Ven, . ss ss > woe)... LOB. 3 Rudd #1VOOE DOMES. os kk 6 sdk so OD ete ss GOs vo 3 Areas of Operating System Responsibility ..........8...... 3 RL ere IS, 6k ic bk os +e toe tesingee& 6 RRs ss 4 Rane, ra ek 8 ee os 6 eo De Oe 4 Ree. APO) DN Se i i ei es Boosie) . Bee 5 ReeTer ie BUNS 66s 5 6 te Oe eo ew ee 6 A ee eh) en oe 6 cue © PRORU F e, P s eo Come. O8 7 ct) ARO IRO SS ba ke bk eee De wD a i EL 8 Picory Cr aapetetini Systems | 6 kk ce HAS we a le OR 8 Mok 8 6B Metalhiw. se... . . eotteria ul, Bis eo we Orel 9 koe - BStel Operating Systane ys... . . ate Jo ane 9 13.3. ‘TimeSharing Operating Systems. . «ods. ew www. oS 10 Lo4 - Destined Operating Systems) «144.5 . ot), .4 11 Techniques of Organizing Operating Systems ............... 12 a4? Miao Designs. . . KIONMARIOSNY wen Tee. . bodes s 12 2h Liperen IN ee ee i a so RR; ob i ba MicsOiernel Designs... «a4 4s. SOL, . dee. ss 12 44 « Viktial Machiie Designe ointink viiwot.ci tek, . 2b. 14 Bootstrapping. 25) mG Seiko jaobitagetel awh. . Pas «a 15 Syne alee ae ce + ATT, PM. Pees 17 LO / eaeple system Calls, 23 vi ket es SO, in| L62.. Pye Call Mechanismiaw sistas esis ak RRS, 18 SUM ee A EE PO ee RN 18 Re wee a oe ee oe eee 19 Example Operating Systems a1 So. Sipser rh... nk wie see yo oT). oS 21 aiiinabOrgesization . <2 « oe o RI es AED. 22 SE OCRINE Senta e dig Aad i ee Pe A OREN 2 De wo 22 vii
- 16. vill CONTENTS 72. «Multies 66 1.wGei- i ass oe ae Ee Oe 2 oe eee 22 Aide Organisation: < sis s 9 sae 2s! Foes ee ee 23 923°" Syetem Galle rye Pew be co aoe, cee oe ee 24 ye 4S > rere rer tre 24 Docu LJORMILIEGEROIL 6 4% oxcn ro Dies 6 9 eee ee ee eee ee 24 24S retin ai. sfc. ss sk he ae BAe are eee Slee Ae 26 Za.ts IPC RRISRO ke od ve 0 ee ee ee ®. e 27 BAS te Settee ieee, Sy. 5% bk 0 Eee oe 27 BE VANEES cilvstate cS el satin LPR ga og a oP cnr 27 Gil MeeOrienination..: ..5 66 bos 2 8 8 0 2 Oe Ole ae ee ee 28 2.5.2 Booting... ..... . . SRS, Geers OL eee 28 2.5.3 . System Calle. ... +s.» . QORe) Op ee 29 2.6. (ASBSD~ .45.6 448 esa a ce > ee a. aera 29 2.6.1 - Organization... 4 ¢. 5 + as & = FR ORE. . Peake 30 2.6.2 . System Calle <0. <0 41 0% + « » SURIOER COIL, 5 Bales oon 30 2.7. Windows NT. v4. « «. WOU ae oe ee ee 30 24. + HOreenigations. «5 9.0.54 45.s63%-0 on 4 Oe 6 Fae 31 Pe Si0 ee ee eT ee er ee es | eee 31 2th + Organization. . + 5 4.4 6s <5 <6 5 6 ee eran: « Ce 32 2.0. RED ak ee eke eS ee ew De oe a ee ee ee eee 32 2.0;L° . sOrganizationie « < so8 «space 4 we ee) x ee sae aes 32 2A SUMMA av seh aw 6s Se Bw BSL Og a eae) ee 33 Dale FERPPCIBES a as Sc RW sow ke en sc eae 33 3 Inferno Structure and Initialization 35 s.1; Origins of Inferno... , ... <a baiteted Baan. . £22. 5. 35 3.2, ,Fundamental Concepts . .oinivwo lee onbae abl. « BRI... 36 30 -Organization: 4. 4... . «abe. Seibiewels feelited). . & 2422.4 39 3.3.1. Basic Architecture: .qJapeet Werekeeuet) Ge.eenotadodl « th 39 3.4.2 . Source Code Organization . ...agueedts addi. . $22.5 40 3A, Initialization. ..<....4.. «sss «2 « Oe bol. . PR 42 a.4.1 . Starting Inferno .......«. .sphet hielo. . 2h4. 0. 43 34.2 . ,Host.OS Specific Initislizationsets quill ios. . be 45 3.4.3 Host OS Independent Initialization ................ 47 3.4.4 Starting Time-Sharing .......s +>» +s «Shik Gi Oe 50 2.6, oystem Calls ...54 0: .,. 44°) aCe Sie. Pe 52 3.6, SUMMary . ss .c%4 ss 106 2 se eee Cee 52 Ou? Eexercises, 058 75 4 Gch a a bya: <a gtig eae 53 4 Linux Structure and Initialization 55 4.1 ‘The Origins of Linux. ... ..... Aa Soa) Alaa eee 55 4.2. ,Orgamization isl: x 4-«cts els «sees ae eas 57 4.2.1... Basic Architecture. ...<2. >. 5 . GO Oe 57 4.2.2
- 17. CONTENTS i Sao ©6pseures Code OrganiSationyysste ly).cencor*t Wo. olkiw 2d wiry 59 43. Initialization wt: oe .. 4Pe og a x a Re ae Ree es 61 Sik. OULSeD EAN IY os ss AIS woe), . A, 62 4.3.2 Processor-Specific Initialization .... 6.08 ¥...0.0... 65 4.3.3 Processor-Independent Initialization. ............... 68 G64. Starting BimsOhering’ (6. we weele, 2S 73 4.3.5 Initiating Administrative Initialization .............. 74 aiey ,ype AME Gk ke ve ks csew ME eee, . BSD... 76 4.4.1 Application-Side System Call Handling .............. 76 4.4.2 Kernel-Side System Call Handling .....7........... (i) SO. +CURD ieteeIee 5 ce a iw oer, . LBD... 78 WG) (Perce a a. ek i ck ae ee mow, . SSD... 78 5 Principles of Process Management 81 Bae. anes acme (aren, x 8% se a Os BIS weit de® - .s 81 Bcapeepa secon: Lins... «5 fa 3 s+ alle eae © DAD. : 82 Rapa Praca Cirigations®, 4) 6 isos + ete earth S PAA: 82 Gan process Dlink. Fa ae aE eet HDS 84 Rae, ect rocesiabieen, 66g e > ss © wellrbedst: 2 RAB os 85 a Tee oss ee ee a ew rie oe ee IRE 86 ahd rca, © os o% 4G als 6 Oo sos ele eee, Ec 86 Dita. Fitet-Come, First-Sarge aenG bse aisil consort) » 82a. s - 87 ihdtieer Eengteet’ Jon Firet, 7 5.6 4 +s weka oe Bete: s Lae x. 87 n> »een Sean ae oy seyp Gs le he eee SS 90 BAe Pricey Gaweulines. «s+ 5. > + elle mes « LAAs: 90 545 Adjusting Scheduling Parameters. ..)2)% hasrtl. . LE... 94 SG Dwe-eewel Scheduling. ..:4 6+: s+ satlebaths 1. 8oem. ss 94 BAY. Neektime Scheduling. «45 pp ss oe TH awoke .>% 94 5.4.8 Scheduling in Embedded Systems .............5..4.. 97 Bb. Geetestuitritnes... oo i e's da > s ede Seed: » ERGe ss 97 5.6 Procesa Creation and Terminationiict pjawidl ua aeacies « GN as @ : 100 Be Cyn Betiont og gg bebe ee oe Cable OTS. c; 101 Bienen Control . .46i5 63> * ee ee» s oes BR 102 Ete oe Paces Wester se yee eo oe ee Re 103 ES) Pobersrs Alecia, . ae so se pee + OF 104 Ce amare og 6 ea Pe eo) eerie Ub 105 Brrr ee ae es Be we wee hE OI GEle ee WY BS 106 6.7.0 Message Padsing::*. ..... oarsiel ai Jamegaual eos 107 Se PROP) a a es so Bee, ot 107 2. BiealOCk Men 4 wees a a a ee es a eo I, OTS © 109 5.8.1 © Necessary and Sufficient Conditions»... anew. ode ee. Hide WisitieeDeskngewith Deadldck: 35 2a). wimew. ee. se. ws 112 Bo. <Sivmmaryaller ees PG. vs ee. BRU, ers. 118 Boy. Gecrcisesee aur Mareen... Ole eemasel. feared, 6 di. 6 118
- 18. CONTENTS 6 Some Examples of Process Management 121 6.1. ._.GISS. 5 eeese. .. «ee ee we ee 2S Se 121 (ope atl Process State. ....<004%« =. « > Seti « Jes 121 6.1.2 System Calle... ..acienedl oli eereree 6 Bas = 122 6.1.8 . Scheduling ; . acdisdlv ain) iachoyeted- eer bbs es 123 62 .Multic8e.a.Va Re. po a os EL See. ae; 124 6.2.1 Syste Callewiwis. Jann wen vealadAéA prilawial . 22s «ss 124 62.2 ProceseSiete ...¢6+ 04s 0 0 we ow ow oe) OE. ob 124 6.28 Scheduling aaiiedts. in untiwe witeanteniagh.« Lab. G. 125 6.3. BIL). ioe sehen... ellen ie) ee che oe... £22... 126 6.8.1. Bysteny Calle... . ened een ee eswe we oR ee 126 632 “ProcesppState: 4. «25 « > ees 2 a Se) 2 a Se ee 126 G23oes Proceds Table icy kde 8)b« el aug ale ee, ee 126 63.4 Scheduling... .... SI RUReOS AEP), Sere 127 6:4. -Sith BditionNDG a. 4.5 22 hae o oe RS rae 127 GA mebyetem Calls, cst 4 aes pe oo SO eee 127 6.4.2 Process State: «a aa ac a ts SPOIL PI. . FPP 128 64.39) Process Table susie xaa 1 Sa.5 ee ee a os eee 128 644. Schoduliey .a.c cass as 5 5 POP BI OS. . ae a 128 66. -€3BSD. (3444 00vS ea ee os ees 2 ewe eee ee 12 65.2 System-Galls.. 4. 4ee4sevee+52+0 9... .* 129 6:5:2i8-Process State and Process Fables. Ga. Pes a 130 GeoeesSchedtiling «3.4 s¢i vans © OP re, .. FPS, 130 66° VMS. «.c6%8 tea ivi ace 1 So Or .. Pee 131 6.67) “=Dystem Galle Py eon 4g 14.1 SPER OL . Peete 131 6:62 “Thread'State, . .“recd yes SQ rear Ge, .. See. 132 6.6.3 sbehedulite ty i.11.4..% <0 See Pee. . PPS o 132 6.7 «WindowsaNiDy 4.4 <i 6 «4-0 a Oe eee, 2.Oe 13a 6.7.1 System Galle. sayy SOs, See, . Pa. es 133 6.7.2. ‘Thread States sate hss «4d so SORES Aes 134 6.7.3 - Process and-Thread. Tables’ irre. Quy ste aet,’, Soper. 134 G74 Sehedulingooy.. 4.45 «54 oe de « OR ee ey 135 6.8- “PingOS! iy a8. ee ee ey ee eT, JS 136 69: -Sen-.. Pye Me oe ie eh otoe RR A. BS Sy 6.10 Summaryc 18 + S954: . «a ee.Pe 138 Gill -Hxereisést- yn nsaacdscicar tales SRS. Bie 138 7 Process Management in Inferno 141 T.1, ,Processeg:in Inferno. « ia. 4. «sa sa 9 ss a ee eee 141 268, BrocessStetem Su kaeweeh < ok aoe ook be ee 142 12:1. - Kernel. Processeaw.ic Hoge eit bee eee 1B 142 1.2.20 User Processes’ ..;...4..... daiwa die adie 2288: 27 143 7.3. Process Data Structires’s...0... 5.54 406 ao ee oe 145
- 19. CONTENTS 7.4 7.5 7.6 7.7 7.8 7.3.2 Kernel Process Table Entry 7.3.3 User Process Table ‘ hOG> Weer eeter table Entry... . vote Wl aeltoglet, . bT... ROG GNGSMON ge6 va eA, siteZabhwE, . bOR.. , 7.4.1 Interpreting the Process Creation Instruction .......... 7.4.2 Implementing Process Creation ..... Wut. ee a... Proness Degiieem wits bee es Qe eae, 6 LD, 2, wpeetes eae ee oe es ee ww ee vo Bel. bOD... ol etAding-40:the. Ready: List»... « weve, haga, . $08. v. 7.6:2° “Removing from the Ready. List.) vg wieitl. POE... ‘od > SENDS OUATING: Voksen . AIO ob ge), . aOR, 5. 10.4 Tenn 6 Tae DOCe. 4 ee) vento. S09... SUE Os AE ebhodiad ol owed pool . . 7. ee ee a OK Sal eA OW ed oe ee 8 Process Management in Linux 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 Process ana*Threada <<. . sietepeial. yom, jo ertimnexy are eee eieke dP iireeiistig hinwe VW «ne ae ek ow woew ee A OH Bae) -Peoeess Helatiodsitng «i eee es wea sw ev SO. 8G Sysco Caleo vgs, «09. ay bere, primis denodel,. AAA » o . Pree ees CSG bi cs bee ee 2S I, BeBe «3 Proecss -Tabieeag $i 3 Sree, le") ets Ageaige,. eo $5.4 - Handling tha-System Gall “Pois Paine: ome, a. oe. Si.22 Crostinvihe Process «oc ee Ue, SA es B6.a ArchitectureSpeécifie Dteps ne 6 PU eRe. . Broce tecseemet PA sat’: oh ee gete Ae POP RE 5 Ot er ee viorities sv ss ss OOPS PR ey... PAD os Ree Ouse Structures oe es tre EO ee, ee S65. 2 Cieek Vicks Gots 545 1 OR Ps SSD Ch ee ee ee ee PO, PMP oe Sree ss tc ee a ea ES a COE Sas faa allea le ee a a a i eM ao 9 Principles of Memory Management 9.1 9.2 9.3 9.4 9.5 The Memory Ficrsetiy. . . + + + dptigaeeM oigs tt, AOA a oe. Address Tranélatioges. ote dabiyeR seed ben yolquenc. 2GOP . . Cou Shaee tilt; Registers: 6 ee de he ww we8 i eo CURT 2 OM oe ements os ee eer ig RU oe AOA 9s Doe Padi Or ee eee I EN BA eo Memory-Related Servicesia-y i ieetinegincth some wile C06 6 6 Memory Layotite ("2s . (DROW OM Eyes 208 BUIQAAME. DO ee Memory ‘Allocation Techniques." suvives. ideiesivreit. oA... Cir Pree- Space Management 808. 6 ck ea ge. ekMe xi
- 20. xii 9.6 9.7 9.8 9.9 10 Some iKO)At Oe 10.3 10.4 10.5 10.6 10% 9.5.2: Fragmentation ..é i.vqeetaetis |. seri, 9.68. Partitioning. «.«s<+ #. sts Se 9.5.4 Selection Policies. .... ylreloviel sae 9.5.5 Buddy System Management ......... Overallocation Techniquea nels). wens J on). ger 06.1 Swapping. .... lovee keer ening 9.6.2 Semmeént Swapping. ...6.+s.0%5 5 0s S65 PaAmeehietes «iv bees 04d s doo OO 964 . Paged Segments... + » teal sthewl agli x 9.6.5 Memory-Mapped Files .:.4 s)s0). eeu 06.6 . Coppa Writes. ..es vers ss see 96.7 . Pedormbnce Issued, . ..... ele sill wae Memory Management in Embedded Systems SSI ARNE So yao ieol eel Re a ca ee ae EE RU a aed weee ee le Bee See Examples of Memory Management Wi a eee ke PICS Mseo eeieias op ht plies 2p Be 10.2.1 Memory-Related System Calls ........ 12. WNTere EO a reng iste yh oibe SD 10.2.3 Segment and Page Management MRR Pore ee ee er ee mera eee 10.3.1 Memory-Related System Calls ........ 10.3.2 Memory Layouts... 5» » » leew ae ee 10.3.3 USR and KMON Swapping ......... mien: Toone os ys pw geo lie ae 10.4.1 Memory-Related System Calls ........ 10.4.2. sMemoryLavouts .o; + 5 » ys + « pee 10.4.3 Free Space Management ........... RO AA lone tore ii ok Calis cone oles eal 14D OG OMBIN Ges isos oy a:sk peo es wa oe BE De Rtas ' h eAZ Roiica. nk A a tt eo a 10.5.1 Memory-Related System Calls ........ 10.5.2 Memory Layouts 10.5.3 Free Space Management 10.5.4 Swapping and Page Replacement VMS 10.6.1 Page Tables 10.6.2 Memory Layouts 10.6.3 Free Space Management 10.6.4 Swapping and Page Replacement 10.6.5 Memory-Related System Calls Windows NT CONTENTS yaa. BE v do 224
- 21. CONTENTS ieee soya Walle le) eatexe, moan” aly satbaod, wa)... OTe? WACM OEMs iis cc se. coOROR pads BOL. os nvr Fr ope Daenemement . 6. ss etliwd eqad auleesowl ei... 10.8 SEO ee) MOONEE ofail Siar giivboewl. vleddld « » 10.9 , Ra, TE ee FE veered wand ered aiilbavdl. «ddkod v « LAP TOCOUR ee Seta dare ere Pee SY Oe re: TE gn, Dey Toe Sy YONG 6 vo oR > 6 toes BY Wes Fonmuageioney 3 TI. sa eR Re ee ews 20.20 Simmaty Piet. on. ses dOegenM en es OV Lo welqivak LOL Eieenriaas Perr eS ORE eretereedtie OO ttisher ld. 2S 11 Memory Management in Inferno ie See. ice rs esx sks a Bbeneienl® Kako: EM? & 4 i aE ee ae a ee er a oe aa re 11.3 Memory Management Data Structures... ......... 00000058 SR RO i a i , Vie a ne 6 RUgeet UIA LSS 8 sf git Grae ie seme oS ek, Ye aQigiteg x #2 11.4 Memory Management Implementation ................0.04. Betta FCN MACEGOTS 9a. 6 gas 82 + 2 les ake PA op enta ee 11.4.2 Removing a Free Block from the Tree............... Rave |POON ENT eS ee ek ty teas ad 11.4.4 Inserting a Free Block into the Tree................ 1 Cree ert PE, en 6 Re es Feo ge.Hyg 2-2 Re TOMEREG ee25a ob Soe) Hepatetn + Re Sutae Serene ekb-8 Siece Reemereens SR a eb et wtPee tae Gage ee 11.5.3 Very Concurrent Garbage Collector ................ Brace eee VOGCO PPT ee a he be Re ea a Fi? ee Ae ES Pa eee ee beet tes Ee he eG 51.7 OO Fer ee OR et. ee he ne ek wePe ee kL 12 Memory Management in Linux Be ior y Beene Dit Pais PTA. © ok i eK ee Se TAs AE ee ee ee ee ee ONS ee ee ee ae pees Bincamong <9): 3 45 ue kk A ee A R21) Ronee eee Allocation <2: aes 46a 5s 2 4 2 oR Be ee RO ee aT a ea i eee, ee $2:8:5' ‘Kernel’ Memory Allocation 214+2: 31 “e" ¥ PROGRAM.F4 19.4 -Pave Managetiont Yo ON OVE es eer a OR Oe Sood VOPR TS. 6 ke Ee 8 ide ee NE 5 BN 1243. Pode Replacement s «vy cers ee ye ee EEO 5 748 12.5 Memory Management Data Structures. .... 0-5. . eve ees 195.1. Représenting ProceassAllocation ¢§i. 6 ee Wee e AMA BA 12.5.2 Representing Virtual Memory. Areas. ... 2.1 .(i wt 12.6 Memory Management Implementation .........-..guatda.com/cmx.p0...005.
- 22. XIV 12.6.1 Handling the Allocation System Call 12.6.2. Addinge-Region. .... os «..SeWA GS 12.6.3. Processing Page Faults .....Uss 5. 12.6.4 Resolving a Fault for a Missing Page 12.6.5 Handling New Page Frames .......+..- 12.7 .Qaaaty Oa c e ee e 8 oe 12.8 Exercise eat WN PP sc ev i 13 Principles of I/O Device Management 13.1 Elements of the I/O Subsystem ..........++.-. 13.2 I/O Device Hardware Characteristics.......... 1821. Disk Deives? SO 0c ee Oe ee ee tay Herm Coemunicationsee ees. se. so 58 13.2.3 Controller Interface Techniques ........ ISS >Tepe orl /O Deve irs ol Pera ee ee ae ee 13.3.1 Communication vs. Storage Devices ig.ose DUreait Vs. DIOCK Lovices « . < so sos = « «5 = 13.4 Objectives of I/O Subsystem Design .......... TOT pO I CICERO cee kot ce ae eee eee eed 13.6: Devies: Drover structure «a. 5:. . s x'e,k Boece ee a8 13.7 Device Management Techniques............. Leiotm NWR RE a ns te aes ae iG(ne eee BS Oye MIALES ECE Ss 1) aan eo SEY ae apa ie Teo PECURLOn DLGGrEn EY sc, aos stack ox Bilaoaan 1S igAe a HB EN oeerr PSSeer set: aaa ae Ue 7a AGRE RAEES gas 5)a.5,x 0 a RO ci wl 13.7.6. Human InputProcessing +0. ..<.<+s«s >» TS Acie» UIC NOIRE fora: iy asmp a, heel ema We. TSB CUT ON iA Ms a ia ek Nise gtk ene mate ale 13.9 Eeercisesi ty caine 4x45. < cos oo aR eh eee 14 Some Examples of I/O Device Management aT GI SS et Ris Ri ec ac ee ee 1.4.32 Mivltics a4.) Aa emule se) i i ae ee cee (473) Rae 14.4 Sixth Edition UNIX 14.5 4:3B5D 14.6 VMS 14.7 Windows NT 14.8 TinyOS 14.9 Xen 14.10 Summary 14.11 Exercises o ip 8 le Oe oe SP es, ee ee Se ee eke oo ee bh BS 1S Aa me Pee ae eee atoe a fe eee” ae 1s © em 46 ee ae re eee) AO.0 hee re CONTENTS (eke eae 309
- 23. CONTENTS 15 I/O Devices in Inferno 15.1 15.2 15.3 15.4 1 1 a 5. 5. Device Driver Structure .. .% Petals Port Brett aes 6s a ss x wertlowd wall, wht. 15.2.1 Servicing a Write Request eres ee 2. Pe ew a Oe A Peis SA ais Gee © 1s ERP eee Rs 2 ede A is keen ba 8 Dey UcomeOn eres Te ss cs . searnlwtote OW eT os 15.3.1 Initializing the Keyboard Controller................ 153.2. Mandlingia Keyboard Intersupti(). iia ovis deioegh. ATL... POA Saris? Pisin ee. «tnigedA bin silialel. fst a 15.4.1. ‘Processingan.I/O Request... . ewotwtat? avimaw. £2 15.4.2 Initiating an IDE Controller Operation .............. 15.4.3 Handling an IDE Controller Interrupt. .............. Suminatpeewes Bow cde ss Joeerveenel oon? oodl. 4144.0). ss neCinn aes PAs os ad so ss RD chee oka os. 16 I/O Devices in Linux 16.1 16.2 16.3 16.4 16.5 16.6 et ee a ee a oe (Dee: ett Ioterrant Handier Structure. 5... 4. « emesis sfebeTde .+ EE a ne a en a ee 1G.cc- Handling the System Gallo hassisss-etteecs tits collared. at 16.3.2 Selecting the Proper Low-Level Write...........4... 16.2.0 .Writing Byte from the-Butler’... . ¢4.4:;. . » dfusmeaes at ae Donieuring the Controller ... 3. so. ns ss + eee:2B Pe RENNIE Suita Gig oy ys afent eas naptes milena ae Sie awa” aus a lal 16.41 ‘Handling the Request... . ...e.ratey? ali to. soca a.ow 16.4.2 Scheduling the Floppy Operation ................. 16.4.3. Performing:a Floppy Operation ¢ ak. GeiD.owi. 2G... GAM. Dtesting the Command acinert all Lee ier. bad. ss [45> Preparing forthe Data Transier........6.>. «mii. oA ISAS. ‘Frogrammizig the Controller... ck we es oh A 10.47. datdling a Pioopy Interrupt... ... ied ati aie. Bx 16.4.8. Finishing the Floppy Operation ............) diab. 64 BRPRREAE hee Ne e ea R Ree We on i ee a et ee ee 8 17 Principles of File Systems Ue 17.2 Rite e rarer Cetera le Ge te tw ee Ae Re 174i1 Shared and’ ExclusivevAccess....... . ehh ai. eeeniere Lys) > tNcccss Patterma Saree «a ss ss IS SE oe. oTY.. £4 S7uis) RY Btpactora,y: Liles: Seerdh.* ooo xe abt. fb... L7el a aMetadata... ..« «0, wee et bere cio, S00... WAS. Memoty-Mapped Files... suvant.at wageeton!, 02... General PileSystem Design ..... 4.6... mgt oaietl dowledl . 24 oa. Peed ot the Pile systenerra doateA.ot ates. 1. XV
- 24. xvi CONTENTS 17.2.2 Major Data Structures... 2» « SPM Sl BRO A 405 17.3 .Name.Spadege. talwdiwis ss + 0 cums » » SONS POPS ey 8G 406 17.8.1 Drive Specifies: jis «2s. « « I ees ee 407 17.2.2. Account. Specifiers...... Weevwes snes & AGES CMI. atee 2 8 408 17.3.8. Hlierarchical. Naming «0.0.» G2¥7) S°QNS @ RINIITET. smear « a a 409 17.8.4..File Extensions... «ss 0 00 +t 2 0 pl)Weeer eterere Gree. One 410 17.3.5.,File Versions . mUawue 2?nwoteelet acta Lee « . 41] 17.3.6 Special Files and Directories 2. ib. 6 ee ee we ee 411 17.3.7 Relative and Absolute Names... .. . .)MWIN bee ee Be 412 17.4. Managing Storage Spacteaswiew og, 47.1. BRI, che cm 412 17.4.1)..File System Mebaiate wre una’ 3 ne BIG, LBs « 412 17.4.2. Data Unite. werd). ernie. ae leer, ee oe 413 174.3. FreaSpace Management. ...:1..2<s.2 4s VINE. Oa 413 17.4.4. Regular Piles disiy Yxted ees 2 8 es oe , Sa 415 A ee POUTORRE ORE 6 css. 22a 8 9k tee ern Bae ea 418 Wek BORKes vecnce sieen xan 6 Reecarnigds # Sundaes 2° Ue eee ae ee ae 418 Lite WDivectiries sas 4.28.5 ut + v.55 os ee eae 419 DY > 1A aseties. totus, SO ee Fee ene Ee ee a ee 419 1s ~GonsistenomC necking: 3.< 7 %-+ 9.2 9 4s. €ohn ee ee ae ee 420 17.6 Journaling and Log-Structured File Systems................ 421 1%.% (Block Gaching * 02 :.g eho ee te, Ee Behe gees eS EN 422 17.82 >Simmeryicceset sk8 ek Se See ee ee ee ee ee gs een. 423 17.0. *Begercises ys 609 6g 3 OE bk ee oe ee ae, Ces aed 424 18 Some Examples of File Systems 425 18.1. QTSS. 75. 2os.s..6 5 OMe Ope 4 a) ani CRA: sf 425 18.1.1. First: CIss File Systemearws) you 4 ¢ eta. -<Lae 2s. 425 18:1.2.. Second CTSs. File System. Doanaau) sit yirss sees 5 426 18.2 ¢Multics (2 Pe. Ss 2st Bes et oak walk sactsaeerrt ses 427 18.9 RIA. 26. tin ai os 2 SO Pe gourmet 1A 428 18.4 .Sixth Edition UNIX) ; «. « « speneeiekaged) ss palbegil 8 oo. 429 18.5 -4:3BSD. ». <a 5 os >» SRR eee aly Sale, CAE 431 TOG VINES hes at aie Ge ae ow ke NMS Rn asnt le pa aT a 432 18.7 .Windows NICS. gh ss sky WM BS eS 2 434 TRS Summary) Pao eed ek oo Re ee eo ee 435 18.9 Exercises . 2 ii 4 6 ees Sec cae ey OS eee 435 19 File Systems in Inferno 437 19.1 -The-Role of FileServera ...... <..0. RA 437 lOcisle eTheiStyx Protocol, ... .i.¢ - ae ei Bee 438 19.1.2. Built-in Kernel File Servers... « «.8ishewb LT). 2 441 19.1.3, User-Space File,Servers.... 20 egies 0. .. 44] 19.2. The Root.Device Server; « .« .« < ... Spiel weeieve SE Teeeeets 5 442 19,2.) Providing the Names. Servedyater® oif4.5:14 Iooe. J LESS oe 443
- 25. CONTENTS xvii 19.2.2. Walking the Root Server’s Tree . 00.0.0.) ue. 8 444 19.2.3, Reading from the RootSérvers. wil eis gaulummen. .. .. 445 19.3 Generic Styx. Meceage Handler edwill!.:.ncihulodsgowbantl. .Qn08. .. 445 Mi) Greatinewirectory.Potry..........:. wae. Te 446 UP5.2. Apomerekiogg Nemee on. ice i ee ee ee. 2 446 tc “Wereeeeeireetnry Tregiviks 6. ee es 447 19.4 Mative Infertio FileSysten «oui .oote.2 uelteiag?. w eolaival: 450 iA Teeth i. c e . SORA al 451 WAZ Maimwerver.Process ..chwiwead busrgime Lowell. KIS... 456 1943. Proceating a: StyaRequestt acideal dduewtiews). 2.18... 456 T2a8 Wales Directory Tree... .. 1... - Sieeida. fhe... 458 45. Steshing a Directory sisi casos mela). 218... 460 ISAC Rees irom b.Pile . y+ ahricwanetl cad Feat. Alf « . 464 19.4.7. On-Digk Date Structures a ijax todas. obtoanglkl .DellG< :« 466 WAS, Keading 6 Directory Entry ....» aaixwer avoresh cual. 21 471 EAD ee INS BO oe To yo apne to beste obec lR eo A471 1.4.10. eating MileBlock ... -ccun ign S403 ageanaieds ote tes < 472 P41 Procedeign Ieitirect Blocks... . i camagecheisnealle sit (So +@ A474 19.4.13..Petching from the Buffer Cache) ..)sicisp8) nh SO hoki @>« - 475 See CIN Sg ia go homed ie SA eo or ee ieee VRMOIO ie AT7 EG eae ee ee eek eee 478 20 File Systems in Linux 479 le URINE, RR Se es te Le idyit hs eget Mahe pe 8% 479 ee SpE eo aS a a PN 480 Se PACA eI ae foso ge aes aah Oo oh ag adres 480 ee TOS ee Fe Hoag ne oe A Oe 2 8 ey 481 TE I eo ee se Se os ee ee ee OS 481 es Ele ER Po ee oe ee ee ge ee eee 481 PT ee aee EC te Se Ate hp eae gape se sage ee 482 Tae ee OC. ve on aeede ae ee ee ae ne 482 ME ase 2 cE Pee en ee ee 485 eee ne cen Emivien 520 255.5 2 ee a eee es 487 ee eee ee ERS Be. Sc tee sk PP SS ee eee ee ee ek 488 ro cede os AR a Ni ae a a ie ht al 488 90.42" “Genente Directory Lookup'(Part'T): 2. 2°. 9OPE4 Oe. , 494 304-4. “Generic Directory Lookup (Part 2) ¢.5. 6 6 oe o 495 Nye oats Wrectory Lookup? «Pete? OU Pe, ee 496 Saw Haste wirecory search . Cer! Pe, lites 498 A Lok o Directory Block-Searche se. 8!Ste BANOS.eed 501 Gy Mike VOR TEE oe ee it ewe so 3 OU BO sb 502 205k. Lanux Write Systema Wall on wk ee PU A UIOOE . ed 502 6. Cenene File, Witting 4.4 6s as ye so oe OR. Bd 503 RAI NVR: lee otfe hoe ok oe AO ee AL] 505
- 26. xviii CONTENTS 20.6 Locating File Blocks in EXTS:) os ricc ted! fu he ee ehee ee ell ee 505 20.6.1 Identifying the Indirect Blocks... ... 1-2-5 ++ eee eves 506 20.6.2 Reading the Indirect Block8s 2 ....5: 6+ see ee ee ale es 508 20.7 Summarys he sk wee ORT PTA, ket sfate 509 20.8. Bhwerciad® sv RE go ec ee SR QA, ete ie fe 509 21 Principles of Operating System Security 511 21.1 .User' Authentication 2... swale. «4... wiileplieiel .LAGL.... 511 21.1.1. User Names and Pasewordaw . awertt! vin webeis eR eas 512 21.1.2 Cryptographic Hashing Punctiotis: )0 as ert. thee os 512 91:13 (Callberkes oes... woth ~eotoe ag, . PAR wine 513 21.1.4 Challenge/Response Authentication. .........64-2445 513 2114. ‘Orie-Thue Paseworda: . .. . 207.4, Ge AUUa,... CL R.. 514 21.436. Biometric Authentication. 7205 7F Ba, «aes ie 514 21.2 Basie Resouree Protection... « “Vo4 ae ey, Sui ie & 515 21211 ~- ‘Privileged Users. 0% OS OI ee, Ne 515 2129. Acces ty OPU Features 14 SURE. Th BAM, ae oe 516 2122-5 AMenicry Acossai ss~5. SSO I es © 5a re aes 517 Zire “owuple rrovection Codda? nye) Pe? MVP ay ess “se nme are Ge 517 Bio Across Conor uate FP Seer. ic be es ee eee 519 Die Coes ee ers eee oS eee he a eee 520 Dik MLV Omer. | TROBE ho, ba Mla s 6 aie ae & eee kaa eee ae 520 OT oo. Mlen-aetne- Mirielie Athan." sats "ela tes ie aleaeh ons cia 521 A AIO TRELTAOREG gis. 5. WW § gh ON. Rae Ce ee 521 Clty CL LEATIOOL far 5 155 at gee ee Soe ee: ee a a a 521 D1 he ORIG SA GLOWING 5. 2.<5 <scwecs te>ace esdie oe ee 522 Nha) MN ieaaa ed ci aA 6 fede.ck, in 1y 8dBS 6 ee! ee 522 A gt 8 VOCE ya? wTecw yssw! ss Feehan de ie hae a 523 Zed Covert Channel...» » 1 coh 8 aise» Sottero aera eee 523 21 Cp. ODIR EE DOTVICS. Vs «s,s. < 053, aianielet anne eS cnn se 524 21.4 Orange Book Classification. ..... « . eos 5,angele Se see 524 ive l. Division D5...) x « 6-epabaestell aehaeeeenetl arvana iia eee 525 21 Aid. Division. CF 4.5 ws. x sok 4 & we Ss© ah ppd Slee 525 Shes S IVISIGH I. 45 ls wos: a0) a eee a on ee ee 526 ZL 4h Division A’ 4... <£2 ovac8d iced <eeeetll abee ) ence 527 21.5. , Encryption... + 6.4 042 we heared wane? eee eee 527 2lid:ly Sytanetzic Encryption . scien ee,becilb OT be. 528 2.0.2; «Public: Key Oryptography dean! wave E STE ae. 529 21.6 ‘Protection Rings in) Multies que dant eee SRE ee 531 21.7 ‘Seouritytin Infernauie Aries <),<0 cs bccn ee 533 21.8 ‘Seourity. in binuxe.7)0 Gert... Je ae A oe eee 533 21.9 Summary). 3- See «04.4 ee a eee eee ee 535 21.10 Exercises
- 27. CONTENTS 22 Principles of Distributed Systems 22.1 Basic Concepts ......... Se a ee a re Sees pk RRR RNIN gk kk wk ke 8b Pw Ry boule Cane oynebronous Operation. ... 1... ceva eee en eas eB Ee 22.1.4 Distributed Mutual Exclusion ................... an ee iMER POE TO hg 509-4 op 8 ggg very Bde wea ee oh 6 SO i ee ET TE a a aa Cana tar eee 22.2.1 Symmetric Multiprocessing... 2... 6 te ns oeBeGahSG rae ae re eI nen ae RR A ng Ob Ra a Vn Bile gp age TS BeOe Rl Oe a aeot Pr re Ey Ca OEE aOR a a a mT 8 ie Bee IN oe 8 gf tn 2 5 a a re eat a a: Mn RR AO ge OO nk uc ms) so ak ds2 Wee Sie RR A SOR NET So ad ae t a mgat e e e oe eo de GINS ge ad gE eal 4 op da lenadke oe ee CT re Sa og OG eGR ay aed Gh, GN Le aed: gested Dae Ae MR RRM as ie gegl enertytg a Pen ek nl echelons hs eeee sags A Compiling Hosted Inferno Laverne Up ihe Ceonfieurstion 6.03. 1 Sinuins Gicle Ges sien Hien A ie renee toad Develsnment: TOOLS occ seve dint tar, neck aaxnigem Salepe Picaeink ULE dk Ee VION INONE . VETIBDIG 5od Phan dha md wmtyke ea) xuapirst ee waoks se pee Perrone Yamane. eats Gin teehee fhe foauk oteertwes ans nett ene Peewee 8 gk ek pi Sb ek ee ee mene SMU WENT oo cre eleae) So unaaeivics masta cas Sehaage faa padtesa Gans FB ee ae, Cee eS ee ee ee pene ee hares B Compiling Native Inferno Pg bemSS PR eT PST 9 Fa a a ee ee eer OE ahSE Se ha i Ca eg aeaOR rn ne gn A Phe aaEE BN PICONET DOI, (O06 vie ec ew pseis RG eg Fae a CCRIrr ary CHG KNCTTICL (CONIC ULATION gee ie ne © en Beer Ferrites trie, LS, GSO UT RMN es ee ner hs a i ogee gah Peer SAPIENS SLT EEO ei clo 6 eetot ates oak haSAig Appia: Qs Hoe LT pal ecgl Eno, eee et ree ae A eer i ree I eR UEPLEETIS ETCUS ETUC ISRO ch aka a th ak ofgS es or eae od ea eh oe Pe ye a he a) Beek Suggested Readings Index XIX 537 537 538 541 541 541 543 543 544 544 545 546 546 547 547 548 548 550 592 553 555 599 507 557 598 558 559 559 561 561 561 562 562 562 563 563 563 564 565 569
- 28. — fs Pic os Webi ity The> ey ny hie Lep aoe ey ee vw Li abe Abs. ivy. ta ar ten >. LJ ees te ee ee on = | we — “te ’ ia , ° x ° ree : i ae 7 ee eee rn eeee rao: 7 > A io me on 608 "aes . « 7 =i tb be A AD 2 One 20m oly ot ier - ne : P ‘ bon me) a 1906 © S45 ONS : spo ee? ’ » Cee ta eh aa | | @arverse Sere! A . = 6. a . “ - (ae Oe D4 ~~» Gir oe : . , — Os > = oq Li > i = ‘ ac aula 2 . = 7 : : + e e = ip i] a . at a 6 — , as 7 a _ ~; a
- 29. Preface The seed for this book was planted over 20 years ago when I was in graduate school. During the summer of 1986, a group of students collected for an advanced operating systems seminar, under the leadership of Dr. David Cohen. We began with the intention of writing an operating system, but our focus soon shifted to writing a textbook on operating systems. As so often happens, little of our original intent was accomplished. However, along the way, we had many fruitful discussions about how to organize a book on operating systems and, by extension, how to approach teaching operating systems. That, combined with a number of years teaching operating systems, led me to observe that there are several different approaches to teaching operating systems. It also led me to realize that no existing text really provided the instructor with the flexibility to draw on each of the different approaches as desired. The motivating objective for this book is to provide that flexibility. Organization Seven topics make up the body of this book. I begin with an introduction that high- lights history, structure and organization, system calls, and bootstrapping. Following this introduction, I examine in some depth each of the major areas of operating system re- sponsibility: processes, memory, I/O devices, and file systems. The final two topics are security and distributed systems. The coverage of the first five topics is presented in sequences of four chapters each that examine each topic from a variety of perspectives. The first chapter in each sequence presents general principles associated with managing a resource. In these chapters, I introduce the relevant issues, and I present some standard techniques for addressing those issues. In some cases, the chapters devoted to general principles also include discussion of related issues. For example, the subjects of mutual exclusion and deadlock are discussed along with process management in Chapter 5 because of their relevance to interprocess communication. The second chapter in each sequence surveys a number of historic and current operating systems. The set of nine OS examples includes CTSS, Multics, RT- 11, sixth edition UNIX, 4.3BSD, VMS, Windows NT, TinyOS, and Xen. My focus with these is to study in a high-level way how their developers translated available standard techniques into practice. In the third and fourth chapters of each part, I drill down further into implementational considerations. I discuss selected parts of the code for Inferno (in the third chapter) and Linux (in the fourth chapter). However, I do not use this pattern in Chapters 21 and 22. These chapters discuss security and distributed systems, respectively. Because these topics are extensive enough for full books in their own right, I necessarily take a selective approach to them. These rea
- 30. xxii PREFACE chapters present only a few representative techniques. I also discuss a more restricted set of examples in Chapter 21, illustrating applied security techniques. I describe how you build a hosted Inferno kernel image in Appendix A. Doing this is a part of implementing solutions to those assignments that ask for modifications to the Inferno kernel. A kernel image built in this way can be run as an application on an existing host OS. Appendix B shows you how to do the same for a native kernel. In particular, I provide the steps necessary to create a bootable floppy image for an x86 PC. This image can then be written to a floppy or used to create a bootable CD-ROM. Intended Audience The audience for this book consists of two groups. The first group is practitioners who want to learn about the internals of Linux or Inferno, as well as reinforce their under- standing of the basic principles. People in this group will likely come to the book with substantial exposure and experience in their respective OS. They will also likely have some familiarity with some of the concepts and techniques of OS operation. There is a possibility that such readers might not have been exposed to some of the data struc- tures discussed in this book. Any book on data structures will provide the necessary background. Likewise, books on computer organization can provide good background in computer hardware. For this group, the chapters on general principles will help fill in any gaps in their knowledge, and the respective chapters on Linux and Inferno will provide introductions to the internals of those operating systems. The second group this book serves is instructors and students of operating systems classes. Both introductory and advanced OS courses can make use of this book. Typical prerequisites for OS courses include a data structures course and a computer organization course. Some sections of this book assume that kind of background. Other sections are connected to programming languages, their compilers, and their run-time environments. Although courses on programming languages and compilers are helpful background, they are not necessary to study this material. Using the Book A book is intended to be read straight through, from start to finish, in most cases. This book can be used in that way. However, most instructors will not use it in that way. Rather, the most effective way to use this book in the classroom is to take selected material from each of the major parts. The full range of material provides each instructor with the flexibility to select the material that best fits the style of the course and personal preferences. An instructor of an operating system course will choose those sections that support the course’s general pedagogical approach. For example, one approach might focus on concepts and techniques in the abstract. Coverage of the difficulties associated with implementing those techniques on real hardware is traded off for theoretical depth. Another approach might trade off time used to present general principles for time used to illustrate the application of principles through a survey of a number of real operating systems. The final common approach to introductory classes combines a study of general principles
- 31. PREFACE ect with an in-depth examination of the implementation of an OS. In this last type of course, students are often required to make modifiéations to the operating system they study. Such in-depth experience with the internals of an existing OS is also often found in advanced operating systems classes. Now, consider a set of recommended chapters and sections for each style of course. For general principles courses, the focus should be on a thorough coverage of Chapters 1, 5, 9, 13, 17, 21, and 22. Instructors might want to supplement this material with selected examples from Chapters 2, 6, 10, 14, and 18. Similarly, these chapters can be assigned as outside readings. One particular formulation of this type of course deserves special attention. The course designated CS220 in the Computing Curriculum 2001 specifies a number of specific topics that should be covered. The following sections provide good coverage of those recommendations: 1.1-1.4, 1.6, 5.1-5.8, 9.1-9.3, 9.5-9.6, 13.1-13.4, 13.7.1, 17.1-17.4, 17.7, 21.1-21.2, 21.4—-21.5, 22.1, and 22.3-22.4. Of course, instructors are not restricted to covering only these sections. Material in other sections and chapters can be included to supplement the CC2001 recommendations. If the principles-and-survey approach is used, Chapters 2, 6, 10, 14, and 18 should be in the classroom presentation. If the additional material places too great a demand on classroom time, instructors can be selective about which topics from the principles chapters to present. For example, the proof of the optimality of shortest job first and the formalism for name spaces can be safely omitted. Other examples of existing operating systems, not included here, make for good outside reading assignments. It is also quite common to structure operating systems courses with a “hands-on” component. In this approach, students are generally expected to familiarize themselves with and make modifications to an existing OS. Frequently, the OS that is used is a relatively small one to make the expectations more manageable. This book also provides material that supports this style of course. The instructor can choose between two existing operating systems: Inferno and Linux. Instructors using Inferno should cover Chapters 3, 7, 11, 15, and 19 in addition to the general principles. Similarly for Linux, Chapters 4, 8, 12, 16, and 20 should be included. In covering the chapters that present code, it is important not to present too much code in the classroom. Experience has shown that it doesn’t take long for all code to start looking the same, and the additional benefit dwindles. It is better to present a few smaller bits that illustrate particularly important points and have the students learn the rest with outside reading and assignments. The ability to read and understand real code is a valuable benefit of this type of organization. The last curriculum example to consider is that of an advanced operating systems course. Considering the nature of advanced courses, several parts of the book could be used well. If the students have come from an introductory course that did not cover all the principles discussed here, then classroom time could be spent presenting them and digging more deeply into any of the principles. Similarly, the survey chapters are a good launching point for a more thorough examination of any one of them or for a more encompassing survey of real operating systems. Finally, for those students whose introductory course did not include experience with operating system internals, the detailed coverage of Inferno and Linux provides a starting place for such experience. These various curriculum designs are summarized in the following table:
- 32. PREFACE XXivV Principles | Principles and | Principles and Principles and Chapter Only Examples Inferno Linux aor ae V V 2 e 3 Vv 4 Vv 5 Vv Vv v 6 e 7 V 8 V 9 V V v 10 ° 11 a/ 12 Jf 13 V v v 14 e 15 of 16 af 17 V V V 18 e 19 f 20 J 21 J J y Basi lit os) V Y ¥: The chapter is covered. e: Selected topics from the chapter are covered. Features of the Book Each division of the book presents a topic from several perspectives: general principles, survey of applications, and detailed design and implementation of Inferno and Linux. The general-principles chapters include a number of key features. Several techniques are presented in the form of semiformal algorithms that are suitable for implementation. These algorithms are set apart typographically. In a number of cases, techniques are illustrated with detailed examples, also with distinct formatting. Finally, these chapters include a number of historical notes to help establish context. In those chapters that present detailed discussions of Inferno and Linux, I focus on relatively small parts of the kernel that illustrate the techniques and principles covered in the principles chapters. Each function I present is broken down in to small fragments, and I describe each of those in some detail. The result is a detailed study of some key elements of the respective kernels. These chapters also include exercises that ask the student to “get their hands dirty” making changes to Inferno and to Linux. In addition to these general features, here are some of the key topics discussed:
- 33. PREFACE XXV e Chapter 1: background, history, organization, bootstrapping, and system calls . e Chapters 3, 4: Inferno and Linux history, structure, initialization, and system calls e Chapter 5: process representation, process scheduling, context switching, mutual exclusion, and deadlock e Chapters 7, 8: process representation, creation, and scheduling in Inferno and Linux, including the new O(1) scheduler in Linux e Chapter 9: address translation techniques, variable-sized allocation techniques (in- cluding a comparative example), swapping, and paging e Chapter 11: pool/block allocation and garbage collection in Inferno e Chapter 12: zone/slab allocation, page tables, and page faults in Linux e Chapter 13: overview of I/O hardware, techniques for controlling devices, and se- lected device management techniques e Chapter 15: device driver structure, parallel port driver, keyboard driver, and IDE disk driver in Inferno e Chapter 16: two-half interrupt handler, parallel port driver, and floppy disk driver in Linux e Chapter 17: name spaces, storage management techniques, and journaled file systems e Chapter 19: Inferno file server design, the Styx protocol, and the kfs file system . Chapter 20: the Linux Virtual File System and the EXTS file system e Chapter 21: basic security techniques and threats, the Orange Book, encryption, and the Multics protection rings e Chapter 22: resource sharing, synchronous operation, clusters, grids, distributed clocks, and election algorithms Operating System Examples The two operating systems discussed in detail in this book each provide their own advan- tages. Inferno is a relatively small operating system, making its details easier to grasp. Inferno is also somewhat unique in that it was designed to run not only as a conventional native operating system, but also as an application running on a host operating system. This hosted capability makes it significantly easier for students to install the OS on their own machines. It also simplifies the process of testing new versions as students debug their assignments. Linux, on the other hand, is a very familiar system—much more so than Inferno. Consequently, studying it provides the student with more directly appli- cable experience. It also provides examples of some of the more complex techniques not found in Inferno.
- 34. Xxvi PREFACE The version of Inferno used in this book is the release of May 10, 2007. The most recent distribution of Inferno can be found at the Vita Nuova Web site, http://www. vitanuova.com. Current development and recent revision history can be found on Google’s code-hosting site at http://code.google.com/p/inferno-os/. 1 discuss the process of compiling and run- ning Inferno in the appendices. I use version 2.6.18 of the Linux kernel here. The primary site for both current and older versions of the Linux kernel is http://www.kernel.org. Two excellent sources of information on building a Linux kernel can be found in the “Linux Kernel HOWTO” by Brian Ward and the “Kernel Rebuild Guide” by Kwan Lowe. Some of the source code for examples in Chapters 2, 6, 10, 14, and 18 is also avail- able on the Web. The full source code for the CTSS operating system can be found at http://www.piercefuller.com/library/ctss.html. Some portions of the source code to Multics can be found at http://www.multicians.org. Old versions of UNIX, including the sixth edition, can be found at http://www.tuhs.org. The 4.3BSD version of UNIX is being maintained by the International Free Computing Task Force (IFCTF) as 4.3BSD- Quasijarus. The home for this project is http://ifctfvar.harhan.org/Quasijarus where these updates, as well as older versions, are all available. The primary resource for TinyOS is http://www.tinyos.net. Finally, the home for the Xen virtual machine monitor is http://www.cl.cam.ac.uk/research/srg/netos/ren. Source Code Formatting The source code fragments in this book are formatted using Knuth and Levy’s CWEB system of structured documentation. Keywords and data types are typeset in boldface. Identifiers not in all caps are typeset in italic; identifiers in all caps are typeset in a monospace font. Several of the C language operators are multicharacter sequences that use characters from the ASCII character set. When presented here, some of these are replaced by common mathematical symbols, which in some cases express the meaning more directly. The correspondence between the C operators in ASCII and the symbols typeset in this text are summarized in the following table: ASCII Symbol “A AY<>IJIIAIVK IN @® 251
- 35. PREFACE Xxvil In addition to these conventions, CWEB formats octal and hexadecimal constants differently. An octal constant that would be expresséd as 0123 in ASCII is typeset as °129, and the hexadecimal constant 0x123 is typeset as “123. It might seem strange that our printed representation doesn’t appear in the same form as the compiler input that is typed in a text editor. Although today we don’t see this sort of difference much outside of WEB and CWEB, it has a long tradition. A number of languages allowed variation in the characters used for operators and such because not all installations used the same character sets. Some environments had very limited character sets with some not even including lowercase letters. Others had extremely rich character sets, allowing programmers to directly enter mathematical symbols, such as those we use here for “not equal to,” “less than or equal to,” and “greater than or equal to.” C itself defines trigraphs to allow for its use in environments that do not include all needed characters. Beyond that, it has been quite common for published code to have a different look to it, much as typeset text has a different look from the output of a typewriter. In that spirit, Algol 68 formalized the difference between the published form, called the strict language, and the compiler-input form, called the reference language. It is interesting to note that Algol was one of the languages that influenced the design of C, and the typesetting practices used with Algol influenced Knuth’s development of WEB. The two lines of influence have converged in CWEB, whose printed representation I use here. Supplementary Material Supporting material for this book can be found on the Course Technology Web site at http://www.course.com. This same material is included on the instructor’s CD, which can be obtained from a Course Technology sales representative. Copies of the relevant versions of Inferno and Linux are included with the supplementary material. The material also includes solutions to most of the exercises. Presentation material is included as well. Acknowledgments No project of this magnitude can be completed without help. There are numerous people whose support, encouragement, and assistance have been invaluable. I would first like to thank my wife Mary and my daughter Rachel. They have put up with innumerable nights of my frustration and of losing me to my office. But they never stopped believing in me or in this project. They picked up the slack around the house as I wrote. The interest and support of my other family and friends have also been a much welcome source of encouragement. Next. I would like to thank my colleagues, both at FedEx and at the University of Memphis. No matter how hard an author tries to manage time (or at least no matter how hard J try to manage time), writing a book like this affects other responsibilities. I would particularly like to express my appreciation to Miley Ainsworth of FedEx Labs for his support of this project. I would also like to thank my colleague at FedEx, Tim Gregory, for his assistance in understanding TinyOS and for reviewing what I wrote about it. The next group of people I’d like to thank is all of my operating systems students over the past few years. They have been my test subjects for this book. They have made
- 36. PREFACE XXviil do with partial drafts, typos, and awkward grammar. Nevertheless, many of them have expressed support and encouragement for the project. I'd like to recognize a few students who provided helpful feedback. They include Bob Bradley, Jim Greer, Taliesin Penfound, and Debbie Travis. I have also corresponded with several members of the operating systems community who provided valuable assistance and feedback. They are Charles Forsyth, of Vita Nuova Holdings Ltd.; Tom Van Vleck, former member of the Multics development team and maintainer of the multicians.org Web site; Stephen Hoffman, of the HP OpenVMS group; and Digby Tarvin, of the University of New South Wales. I would also like to thank Jim Aman at Saint Xavier University, Charles Anderson at Western Oregon University, Bob Bradley at the University of Tennessee at Martin, Thomas Liu at New Jersey City University, Chung-Horng Lung at Carleton University, Jon Weissman at the University of Minnesota, and Dongyan Xu at Purdue University. Their careful review of the early drafts led to substantial improvements in this material. Finally, I want to express my appreciation to everyone at Course Technology. There’s no way to list everyone who has contributed to this project. However, a few names must be recognized. First, I’d like to thank Mary Franz, who first saw the potential for this book and helped me through the early stages of the process. There are three people who have been there working with me all the way through the project. I am supremely grateful to Alyssa Pratt, Jim Markham, and Matt Hutchinson for everything they've done to make this book possible. Everyone’s input and involvement have made this a better book. Any remaining flaws are entirely my own. I can’t thank everyone enough for all the support in making this a reality. Brian L. Stuart
- 37. Chapter 1 Introduction to Operating Systems At some level all computer software must interface with the hardware on which it runs. It must use the central processing unit (CPU) and memory in a safe and efficient manner, and it must control input/output (I/O) devices in order to bring data in and put results out. Most applications, however, do not attempt this control directly. Instead, they are written to operate with additional underlying software that is responsible for managing the hardware. This underlying software is the operating system. The study of operating systems is the study of software that directly controls hardware and provides a framework for other software. It is the study of the foundation software on which most all applications depend. It is the study of the environment in which and for which applications are written. Consequently, the study of operating systems is one of the most important foundation topics in computer science. Because the operating system runs directly on hardware without additional supporting software, a study of operating systems also provides a good background for embedded systems. Embedded systems include the wide variety of applications ranging from auto- motive ignition control computers to electronic thermostats to medical [TV pumps. Many of the same techniques that are used in embedded applications are also used in operating systems. As we begin our study of operating systems in this chapter, we examine much of the background and questions surrounding the operating system as a whole. We first define what an operating system is and identify what it does. We also look at the development of operating systems over the history of computing. The next major topics address the question of how we organize and structure an operating system. followed by a study of how an operating system gets loaded into memory and initialized. Finally, we address the connection between applications and the operating systems on which they run. 1.1 What Is an Operating System? In order to frame our study of the principles of operating systems (OSs), we need to ask the question, “What exactly is an operating system?” Often vendors ot operating systems 1
- 38. 2 CHAPTER 1 INTRODUCTION TO OPERATING SYSTEMS refer to everything included in their distribution media as their operating system. This is, however, a somewhat problematic definition for our purposes. After all, the images, sound files, and application programs are not part of the operating system per se, and are subjects of their own areas of study. At the other end of the spectrum, the label of operating system is sometimes restricted to a program that runs on bare hardware without any supporting software. This program, often called a kernel, monitor, or supervisor, does provide all the functions of an operating system in many systems. However, as discussed in this book, there are a number of operating systems, where much of the traditional functionality is provided by auxiliary programs. It seems that any attempt to define an operating system in terms of how it’s packaged or how it’s constructed is doomed to failure. Consequently, we define it in terms of what it does. In particular, we identify the following key functions and purposes: e The operating system manages the sharing of resources among competing entities. e The operating system provides a number of common services that make applications easier to write. e The operating system serves as the interface between application programs and hardware. With these ideas in mind, we define the operating system as follows: An operating system is a set of one or more programs which provides a set of services that interface applications to computer hardware and which allocates and manages resources shared among multiple processes. The three key functions and purposes of an operating system just listed suggest three corresponding perspectives on its role. In Sections 1.1.1 through 1.1.3, we discuss these three perspectives on the concept and the role of the operating system, derived from these three functions and purposes. Think of these in the same way as we talk of a person “wearing different hats.” Indeed throughout this book, we look at the functions of the operating system from each of these perspectives at various times. 1.1.1 Resource Manager The most classic way of viewing an operating system is as a resource manager. From this point of view, the operating system is responsible for the system hardware. In that role, it receives requests for access to resources from applications and it either grants or denies access. When granting allocation requests, it must be careful to allocate the resources so that programs don’t interfere with each other. For example, it is a bad idea to allow programs to have unrestricted access to each other’s memory. If a buggy (or malicious) program writes into the memory space of another program, the second program will crash if it’s lucky, or produce incorrect results if it’s not lucky. Worse yet, if the offensive program modifies the operating system’s memory, it could affect the behavior of the whole system.
- 39. 1.2. AREAS OF OPERATING SYSTEM RESPONSIBILITY 3 When we talk about an operating system as being a resource manager, we think of it as the authority figure of the system. Wé even refer to programs as running under an operating system. (This view was illustrated dramatically in the movie Tron. In that movie, the Master Control Program, MCP, operated like a despotic government impeding the freedoms of the heroic programs. The naming of this program is no accident; MCP was the name of the operating system, originally released in 1962, for some models of computers manufactured by Burroughs.) 1.1.2 Service Provider We can imagine that the resource manager viewpoint represents that of a system owner who wants to make sure that the resources are used effectively. On the other hand, we can look at things from the viewpoint of the application (or the application’s programmer). From this perspective, we want the operating system to provide a rich collection of services that make the application’s job easier. In particular, we expect that much of the detail in accessing I/O devices, allocating memory, and the like will be handled by the operating system. When we think about the operating system from the service provider perspective, we often talk about programs running on the operating system. 1.1.3 Virtual Machine The last perspective we examine is that of the virtual machine. This perspective stems from our observation of the operating system as an interface between the application and the hardware. We get the basic idea here by imagining the application software looking down toward the operating system and hardware. The application cannot tell the difference between a computer with very simple hardware with few features and a computer with very complex hardware with many features if the operating system provides the same features in both cases. In other words, as far as the application is concerned, the combination of the hardware and the operating system is the “computer” on which it runs. In Section 1.4, we see a particular way of designing an operating system we call a virtual machine operating system which takes this perspective to its logical conclusion. (To make matters more complicated, there’s yet another common use of the term virtual machine. This other use refers to a machine that is simulated in the sense that each instruction is interpreted by the host on which it is running. Sometimes, we translate the virtual instructions into native ones on the fly. This is called just-in-time compiling. The advantage of this type of virtual machine is portability. We can compile programs to the simulated instruction set and then run those programs anywhere we have an interpreter, or virtual machine. This concept has been used in a variety of systems ranging from the P-code of UCSD Pascal in the 1970s to the more modern Java Virtual Machine (JVM) and the Dis virtual machine.) 1.2 Areas of Operating System Responsibility Regardless of the perspective from which we’re looking, the OS must deal with a variety of resources. It is along these lines of responsibility that the majority of this book is
- 40. 4 CHAPTER 1 INTRODUCTION TO OPERATING SYSTEMS organized. Of the items described in this section, the first five (processes, memory, 1/O devices, file systems, and security) are discussed in detail in subsequent chapters. As we discuss these areas of responsibility, we do so from the various perspectives discussed in the previous section, 1.2.1 Processes The most obvious resource that needs to be managed and used effectively is the CPU. The tricky part is that the very resource we’re trying to manage is the resource that’s executing the code of the operating system itself. In other words, the CPU is the active entity in managing and allocating itself. Furthermore, because there’s usually only one of them (or at most a few), managing the CPU is not a matter of allocating the physical resources exclusively to running programs. Rather, we manage the CPU in terms of allocating fractions of its time among competing running programs. When managing the CPU resource, we generally work in terms of running programs. We refer to these programs in execution as processes. To support processes, operating systems generally provide services including: e creating a process destroying a process changing a process’s priority providing interprocess communication e often providing process synchronization In most cases, these services are used by one process to act on another. However, in some cases, a process might call a service to act on itself. For example, when a process is finished, it can call the process destruction service to remove itself. Internally, the operating system is responsible for scheduling and context switching. The scheduler is the mechanism by which the operating system chooses which process is to run next. The actual operation of transferring control of the CPU from one process to another is what we mean by context switching. 1.2.2. Memory In many ways, one might expect that managing the memory space is one of the sim- plest responsibilities of the operating system. However, experience has shown that the performance of the system is probably more dependent on the behavior of the memory management subsystem than on any other. At its heart, memory management is primar- ily about responding to requests to allocate and to free memory. Of course, in satisfying these requests, the operating system must ensure that processes don’t interfere with each other and that memory space is not wasted. These responsibilities form the basis of a typical set of memory management services, such as:
- 41. 1.2 AREAS OF OPERATING SYSTEM RESPONSIBILITY 5 e directly requesting additional memory ’ e indirectly requesting memory (e.g.,when creating a new process) e freeing (releasing) memory back to the OS e requesting that memory areas be shared among processes As with process management, there is a significant behind-the-scenes responsibility for the memory manager. In particular, in most environments, we wish to satisfy requests for more memory than is physically installed on the machine. Providing support for this type of overallocation (often called virtual memory) is typically a major part of the operating system’s memory manager. 1.2.3. I/O Devices One of the primary functions of an operating system is providing services that simplify application development. This is nowhere more evident than in the area of I/O program- ming. If every application program had to handle the minute details of every I/O device that it used, application programming would be far more error-prone than it is. Further- more, I/O devices are often shared among numerous processes. For example, nearly every application running on a system has need of mass storage devices such as disk drives. This sharing complicates the interactions between a program and the devices it uses. Naturally, we assign the responsibility for preventing problems to the operating system. In managing I/O devices, we generally provide a variety of services for processes. These services often include: e opening a device or attaching a device to a process e reading data from a device e writing data to a device e closing and releasing a device e providing exclusive access for appropriate devices e providing various special functions, such as rewinding tapes and setting serial line baud rates We often also make use of I/O devices as part of other OS functions. For example, the illusion of large memory spaces is normally provided by using space on a storage device to hold less frequently used data. Likewise, if we want to start a process running a new program, we must read the binary code for that program from some device.
- 42. 6 CHAPTER 1 INTRODUCTION TO OPERATING SYSTEMS 1.2.4 File Systems Another area where we use I/O devices to support other functions is the area of file systems. Indeed, for most applications, the primary use of I/O devices is for storing and retrieving named persistent data that we usually call files. For the most part, the file system supports a set of requests similar to the I/O device subsystem: e opening a file e reading from a file e writing to a file e closing a file e seeking to a random place within a file e reading file metadata (e.g., file name, size, ownership, protection codes, etc.) e modifying selected metadata In Chapter 17, we find that in order to support these requests, the file system must also provide the service of translating names into locations of data. We also define there the idea of aname space as the set of names which a process can access. Indeed, as operating systems have developed, the management of name spaces has become a key element in the design and organization of operating systems. 1.2.5 Security Virtually every other area of operating system responsibility carries with it security el- ements. An OS should not allow just any process to terminate another one. As we've already mentioned, we must be careful to ensure that processes cannot write indiscrim- inantly into each other’s memory space. Likewise, requests to access I/O devices and files must be filtered through tests of ownership and permission. These measures are implemented in terms of enforcing security policies in a manner which is transparent to applications. Programs make requests of the OS, and they are determined to be either permissible or not. Some very interesting new developments in the realm of security are in networking. With the rapid proliferation of the worldwide Internet, the need for strong authentication of network requests has taken on increased importance. Finally, there are additional security responsibilities that belong to various administrative applications. These include tasks such as scanning the system for known vulnerabilities, testing the system for unauthorized access, verifying the safety of third-party software, and so on. In addition to the enforcement mechanisms operating in the background, applications can request services such as: e setting security policies e querying security policies
- 43. 1.2 AREAS OF OPERATING SYSTEM RESPONSIBILITY 4 e authenticating themselves to a remote system ‘ e listening for a remote system to authenticate itself e encrypting and decrypting messages, especially ones carried over a network Out of view of the applications, the OS acts as a gatekeeper. When a process requests a service of any of the subsystems, the operating system checks whether or not it has permission for the service. If it does have permission, then the request is granted, but if not, the request is denied. 1.2.6 Networking In many ways, networking support is another application of the I/O subsystem. In addi- tion to the details of moving bits in and out of the system, however, the operating system normally implements protocol stacks. It is quite common for networking protocols to be designed in terms of several layers, each encapsulating the other. For instance, communi- cation using the TCP/IP suite of protocols over an Ethernet interface generally involves four protocols as illustrated in the following example. Example 1.1: Network Protocols In this example, consider a Web browser making a request for a file using the Hypertext Transfer Protocol (HTTP). Using this application level protocol, the client (browser) may send a message such as “GET / HTTP/1.0rnrn” when attempting to fetch the URL Attp://www.google.com. This application message is then encapsulated in one or more Transmission Control Protocol (TCP) segments. Each TCP segment has a header containing data used to maintain the integrity of the series of messages, followed by the data it contains. TCP segments are, in turn, encapsulated into one or more Internet Protocol (IP) datagrams. As with TCP segments, IP datagrams have a header, which ensures that the datagram gets to the right destination uncorrupted, followed by the data. Finally, the IP datagrams are further encapsulated in Ethernet frames. Each Ethernet frame has both a header and a trailer. The overall transmission looks like that shown in Figure 1-1. Ethernet iP VCP Ethernet Header GET / HTTP/1.0rnrn Trailer Figure 1-1: Example of Network Protocol Encapsulation As with I/O programming, it makes sense to let the operating system take responsibility for these protocols. From the application perspective, networking services include: e establishing a connection to a remote service e listening for connections from a remote client
- 44. 8 CHAPTER 1 INTRODUCTION TO OPERATING SYSTEMS e sending messages to a remote system e receiving messages from a remote system e closing a connection to a remote system 1.2.7. User Interfaces The last area of responsibility that we discuss is the user interface. While some designs have integrated the user interface into the operating system, most modern designs break the user interface out as normal application processes. This is part of the reason why we don’t attempt to give user interfaces a thorough examination in this book. The other reason is that when dealing with users, things are often more complicated than when dealing with hardware and the other OS responsibilities. As a result, the area of user interfaces is a large subject unto itself. 1.3 History of Operating Systems The history of operating systems is the story of two trends in their development. The first trend is the evolution from the operating system as a collection of disparate mechanisms to the operating system organized around unifying principles. Even though the areas of OS responsibility seem very dissimilar, operating systems research has identified a number of concepts with which they can be united. The second major trend addresses the conceptual model of computer usage. As we see throughout this section, computer systems were originally seen as being for a single user to run a single program on a single machine. This perspective can be conceptualized with the triangle shown in Figure 1-2. While every generation of computing seems to start with this same model in mind, we always find that we need to add functionality to allow multiple users to run multiple programs and to interact with multiple computers. One One Program Computer One User Figure 1-2: Triangle of “Ones”
- 45. 1.3. HISTORY OF OPERATING SYSTEMS 9 1.3.1 Bare Metal : Proto-computers and the earliest computers were developed with the idea that they’d be used by one person at a time to solve one problem at a time. These one-of-a-kind machines and early, small volume production machines were built from the late 1930s to the early 1950s. It wasn’t long, however, before many people had uses for these machines. So the natural thing happened. Those who administered these machines began to schedule the use of them. It was not uncommon for a sign-up sheet to be posted with a week’s worth of time divided into hour-long time slots. An individual user may have been allowed to sign up for only two or three slots per week. To our modern ears, this sounds like a painfully difficult way to work. Partly, this is because it was a painfully difficult way to work, and partly this is because the discipline of design and debugging away from the computer has largely been lost in a world of graphical debuggers and quick-and-easy compiling. Nevertheless, in a world where machines were rare and priceless, this was an effective use of the machine and programmers had little choice but to live with it. The systems of those days had no operating system as we would think of one today. However, the seeds of the operating system were already beginning to appear. Even with the earliest machines, it was quite common for a lab to develop libraries of code fragments forming the first examples of code reuse. Using these libraries, programmers did not have to rewrite routines to compute square roots or to control a tape drive for each new application. We can see how these libraries inspired the service provision aspects of operating systems today. 1.3.2 Batch Operating Systems There’s a big problem with the scheduling described in the previous subsection. Remember that these machines were very expensive and rare. With that in mind, consider how programmers spend most of their time. For most of us, it’s spent staring at the screen trying to figure out what went wrong. So the upshot was that for many of those scheduled hours, the CPU was idle and the expensive machine went to waste for most of the hour. The first real operating systems were developed in the 1950s to address this ineffective use. In order to use the machine more effectively, users had to be separated from the Historical Note: ENIAC One of the most extreme examples of a machine that could work on only one problem at a time was the Electronic Numerical Integrator and Computer (ENIAC). In fact, this machine, which went into operation in 1945, required rewiring to change the problem it solved. This was true for its initial design. In 1947, a technique, requiring a relatively minor modification to the machine, was developed that allowed a program to be entered on the switch panel originally designed to store numeric constants. This enhancement reduced the time to set up a problem from potentially several days to a matter of hours. ENIAC continued to operate this way until 1955, when it was retired.
- 46. 10 CHAPTER 1 INTRODUCTION TO OPERATING SYSTEMS machine so that debugging time did not prevent the machine from doing useful work for other users. Even today, this type of noninteractive operation makes sense in some areas. Examples include periodic running of payroll, billing, group membership mailings, and so forth. The basic idea is that a user submits a job to the system and then comes back later to get the results. Groups of jobs are collected together in batches and each job is run to completion before moving on to the next. In some of the early batch systems, jobs were submitted as a deck of punched cards handed over to an operator in the computing center or perhaps fed into a card reader by the user. In more modern applications of the technique, jobs might be submitted from some form of interactive session, but still run as part of a batch. Operating systems that operate in this way are called batch operating systems. In some installations, groups of jobs are collected on a smal] computer and put onto tape to be processed by the main computer. In these cases, it is also common for the output from the main computer to be written to a tape, which is then read by another smaller computer that prints the results. These printed outputs are then placed into output bins for users to pick up. By developing these batch operating systems, developers began to break the one user/one program/one computer triangle. The one user leg is broken here. Even though at any point in time, the computer is working on behalf of only one user, many users can be in the process of using the overall computing facility. 1.3.3. Time-Sharing Operating Systems As usual, we don’t get something for nothing. Batch operating systems make using the computer more efficient in the sense that the CPU does useful work for a greater percentage of the time. However, this benefit comes at a cost. When people work directly with a computer, there is an interactive component that gives an immediacy making one’s debugging time more effective. Even though we take this as self-evident today, the benefit of interactive use was not seen as worth the cost of less-efficient CPU usage in most early environments. Nevertheless, there were some environments that did hold to manual scheduling of com- puter time. In these environments (often research), another phenomenon soon emerged. A programmer who had signed up for an hour but ran into a snag would often leave the system before the hour was up. Something of a subculture developed where other members of the computing community waited around for those times when the computer would be free for part of a scheduled hour. As the decade of the 1960s dawned, some of the researchers in these environments noticed that the computer turned out to be more efficiently used when scheduling and turn-taking took place with more fine-grained resolution. The natural thing to do with an observation like this is to ask what happens if we take it to the limit. In effect, we ask what would happen if we moved from one user’s program to another with an infinitesimal time between these switches? Two things immediately emerge from this question. First, it becomes clear that a program cannot run to completion before switching to another. Second, we see that users could not alternate the use of a single I/O device to communicate with the system. However, if we could solve these issues, we’d have a system where
- 47. 1.3. HISTORY OF OPERATING SYSTEMS 14 multiple users could run multiple programs with the illusion that all the programs would be running simultaneously. ‘ These ideas form the basis of the next stage in operating system development. The first step is easy. We just replicate the user interface connecting numerous terminals with keyboards for input and printers or video displays for output. This easily addresses the issue of how multiple users can use the system simultaneously. In order to provide the illusion of simultaneous program execution, we approximate the theoretical model. Rather than try to switch among processes in infinitesimal time, we do the switching with a fast but finite interval. Times of one-tenth of a second between switches are not uncommon. The innovative technique of suspending a running program, saving its state, and restoring a previously saved program in order to give it the CPU is called context switching. This new type of operating system is variously called a time-sharing operating sys- tem, a multiprogramming operating system, or a multitasking operating sys- tem. While we have presented these terms as being synonymous, they are often used with subtle distinctions in meaning. In particular, the term multiprogramming is often more precisely used to refer to holding multiple programs in memory at once. We generally think of this as going hand in hand with time-sharing, but it doesn’t have to. Without multiprogramming, time sharing can still be implemented by writing a snapshot of the currently running program to disk on each context switch. This way, only one program is resident in memory at a time. Conversely, there have been multiprogramming batch systems that allow one program to run while another is waiting on an I/O device. In providing a mechanism for switching among a number of processes all ready to run, we break the second leg of the one user/one program/one computer triangle. 1.3.4 Distributed Operating Systems The natural next step is to break the one-computer leg of the triangle. Allowing a user or program to use multiple CPUs or computers to cooperate on a single problem is the realm of distributed computing. The various degrees to which cooperating systems are treated as one large system form a spectrum of distributed techniques discussed in more detail in Chapter 22. At one end of the spectrum, we have grid computing systems, which are generally identified by their independent administrative domains. They are often more widely distributed geographically than other distributed designs. These systems cooperate by convention, but no system can assume that another is behaving according to the plan. Popular distributed projects such as SETI@home and folding@home can be classified as grids. Somewhere in the middle of the spectrum, we have clusters. These systems are generally administered as a single system, but each machine runs its own operating system. The individual operating systems are generally aware of each other and expect all the members of the cluster to cooperate. At the other end of the spectrum, we find environments where a single operating system treats all the CPUs and memory in multiple systems as a single resource pool. Operating systems written with the objective of coordinating multiple CPUs are generally referred to as distributed operating systems. There is another type of multiple CPU support that doesn’t fall into the class of dis- tributed operating systems. Some machines have multiple CPUs sharing a single physical memory and the same set of I/O devices. We refer to these as symmetric multiprocessing i
- 48. 12 CHAPTER 1 INTRODUCTION TO OPERATING SYSTEMS (SMP) systems. While the operating system design must account for scheduling and coor- dinating multiple processors, the shared memory and I/O devices separate these systems from the class of distributed system. 1.4 Techniques of Organizing Operating Systems As with any other substantial software system, an operating system must be carefully designed. In this section, we look at a few of the general organizational techniques com- monly used. Throughout this discussion, keep in mind that most often system designers use techniques in combination, even when one approach dominates their design. 1.4.1 Monolithic Designs We begin our discussion of design techniques with monolithic designs. While it can be tempting to think of this as a class of designs the are characterized by a lack of any other form of organization, in reality a monolithic design is just a design organized as a single program. As with any program, such a design should be done with a well-organized structure. Most operating systems have been organized along these lines. 1.4.2 Layered Designs We next consider a layered approach to OS design. The concept of layered design is not exclusive to operating systems. Many of the better software system designs are structured in a layered manner. The basic idea is that each layer increases the level of abstraction and is built on the functions provided by lower layers. For those who approach design more formally, the design can be made to follow a layering principle, which can be stated as “no function calls a function or uses a data structure defined in a higher layer.” Most uses of libraries follow a layered approach. In the context of operating system design, a layered design might place the I/O device management at the lowest layer, build memory management on top of it, put file systems as the third layer, and, finally, process management might exist at the top layer. This arrangement is illustrated in Figure 1-3. As we move from the hardware up through the layers to applications, we gain more and more functionality. In realistic designs, the layer assignment is not as simple as the example presented here. In fact, it’s not uncommon for some subsystems to be split into lower and upper parts that have other functional layers between them. The XINU operating system by Comer is a good example of a system that follows a layered design. 1.4.3 Microkernel Designs A number of designers have suggested that much of the traditional kernel functionality could be moved out of the kernel and into other processes managed by the kernel. In principle, this would make the kernel smaller and easier to write and maintain. In such a design, much of what is done through function calls in a monolithic kernel is handled by message passing with a microkernel. Figure 1-4 illustrates one such design. Each box
- 49. 1.4 TECHNIQUES OF ORGANIZING OPERATING SYSTEMS 13 tind Eidos tatoteelate ncetie sc Slltiadllaadlandh Mehhind Process Management File System Memory Management /O Device Management Figure 1-3: Simplified Example Layered OS Design above the microkernel is implemented as an independent process. The primary role of the microkernel is scheduling the processes and passing messages among them. One effect of the microkernel design is that communication between components, that might otherwise take place through parameter passing or shared variables, is carried by messages. As one might expect, this characteristic creates a greater burden on the design of the microkernel and its message passing implementation to be efficient. The risk is that the effort to create efficiencies, in a poorly designed example, can result in a microkernel that is nearly as complex as a full monolithic kernel. Another challenge in the design of a microkernel OS lies in the issue of security. We want as much functionality as we can to operate as ordinary processes. But for much of that functionality, we don’t want normal users to be able to substitute their own versions. Consider the following (admittedly contrived) example. If the memory management func- tions of the OS are implemented as normal processes, then we must allow (at least some) normal processes to be able to allocate memory to other processes. How then do we pre-
- 50. 14 CHAPTER 1 INTRODUCTION TO OPERATING SYSTEMS Applications aos = eas -+» I/O Device Management --- ea Figure 1-4: Example Microkernel OS Design vent all normal processes from being able to do this? One of the most common answers is to give those processes that provide OS mechanisms a special status with higher privileges. Some good examples of microkernel designs include Tanenbaum’s MINIX, The Hurd (part of the GNU environment from the Free Software Foundation), and the MACH operating system, which (among other uses) serves as the foundation for Mac OS X for the Apple Macintosh. While Inferno is not built around a microkernel, we will see examples of how it also moves some traditional functions into user processes. 1.4.4 Virtual Machine Designs Section 1.1.3 discusses the concept of a virtual machine as a way of looking at the function of an operating system. It’s also possible to take that idea a step further and make it the basis of an operating system design. In particular, we can take literally the idea of providing the illusion of a machine. This approach leads us to develop an operating system which gives each process the illusion that it is running on the machine all by itself. In other words, the main function of a virtual machine operating system is to provide the illusion of many copies of the hardware. In such an environment, we can, and often do, run another operating system in each of the virtual machines. Again, as one might expect, doing this efficiently is a significant challenge. The canonical example of this approach is the VM operating system from IBM. Figure 1-5 illustrates this approach with three “guest” operating systems running on top of the virtual machine OS and a number of applications running on each of those. ie ee Applications TT Apnicaices [[Boni Virtual Machine OS Hardware Figure 1-5: Sample Virtual Machine OS Design
- 51. 1.5 BOOTSTRAPPING 15 In recent years, a number of products have emerged with the purpose of allowing the user to simultaneously run more than one OS. The commercial product VMware supports several operating systems for the Intel x86 architecture. These operating systems can run unmodified. The open source project Xen provides very similar functionality. However, it requires that certain low-level operations be ported to Xen. In effect, Xen becomes the machine on which the OS is running. A number of open source operating systems have been ported to Xen. However, because only the vendor can make the necessary changes to a proprietary operating system, there is very little in the way of such OSs available for Xen. One final approach that is gaining momentum is emulating a complete computer in software and running an OS on that emulated machine. While there have been examples of this practice for several decades, it is becoming practical for more applications all the time. For example, even on a low-end commodity computer, an emulated PDP-11 is faster than any of the real ones built by Digital Equipment Corporation (DEC). (The PDP-11 is the machine on which much of the early UNIX development took place. It was manufactured from the 1970s into the 1990s.) This approach allows us to run operating systems developed for one computer architecture on another. Such an emulator can also be used to run multiple operating systems on a single machine. One of the most interesting emulators being used for running operating systems in parallel is QEMU, developed by Fabrice Bellard. When running code for the Intel x86 architecture on an x86, QEMU can run much of the code natively rather than emulating it. In doing so, it can provide much the same functionality as VMware or Xen but without requiring special hardware features or modifications to the OSs being run. 1.5 Bootstrapping In all of our discussion up to this point, we’ve skipped over one challenging issue. The OS can only provide all of the services we’ve discussed once it’s loaded in memory and running. However, allocating memory, loading code from a storage device, and starting it running are normally functions of the very operating system we need to load and start running. The net effect is we have a sort of “chicken and egg” problem. How can we get the system to a point where the operating system is running before we have the operating system available to perform the functions usually associated with loading and running a program? Getting the system from bare hardware to the point where we have a running OS is a process we often call bootstrapping. (The term comes from the image of the computer lifting itself up by its own bootstraps.) While the term bootstrapping is in common use today, many manufacturers have also referred to it by other terms, which are still in use with those systems. Among those are cold start, dead start, and initial program load (IPL). There are three typical approaches to the bootstrapping problem. e Up through the 1980s, many computers were manufactured with front panels. These devices provided an operator or programmer with access to the system’s CPU and memory. There were usually one or more rows of lights (usually LEDs) that showed the current state of various busses and registers. For input, there were generally
- 52. 16 CHAPTER 1 INTRODUCTION TO OPERATING SYSTEMS one or more rows of toggle switches on which the user could set an address or a data value in binary. Typically, the user could use the front panel to examine and modify memory locations and to start and stop the CPU. In some larger (especially later) designs, the front panel was replaced with another smaller computer called a console computer. This small computer gave the user a textual interface to the same functions that were provided by the front panel. Given this type of interface, we can easily move from the computer as a lump of inactive silicon to a machine running a program. We need only enter the program on the front panel, storing it into memory, and then start the CPU running that program. Of course, entering a large program in binary, one word at a time, is rather tedious. Naturally, we don’t load the whole operating system that way. Instead, the system loads a small program that knows only enough to read another small program from a storage device. This first stage program is often called the boot loader, or the bootstrap loader. The code read from the storage device is often itself another second stage loader, which knows enough to find the OS and load it. e In a number of large-scale computer designs (especially older ones), the hardware provided the critical first step. This was especially true with devices like punched card readers. Often, the hardware was capable of loading the contents of one card into memory and causing the CPU to run that code. As with loading code from a front panel, we put a small bootstrap program on the storage medium and it knows enough to carry on with the next step of the process. e For some installations, the system included code for a number of boot loaders in special read-only memory (ROM). This was especially common in larger installa- tions where the incremental cost of the additional memory was relatively benign. In these systems, the front panel could be used simply to select which boot loader to use. This had the effect of selecting which storage device was used to load the second stage loader. In time, the relative costs of components changed and ROM became much less expensive than front panels. As a result, the front panel largely became extinct and nearly all machines are manufactured with code in ROM that the computer is running from the moment it is reset. This code gives the operator much the same sort of interface as a console computer provides. (In fact, most con- sole computers start up running code in ROM.) The operator can directly interact with the machine in some cases, but the main use of this code is to load second stage loaders from storage devices. Regardless of which method is used to get the system running, we end up running a small program that loads the operating system from disk (or some other storage device) and starts it running. In some cases, there are additional intermediate loaders. We usually refer to each of the loader programs as a stage. The most common designs use either two- or three-stage boot loaders. Typically, each loader does very little in the way of initializing the hardware. We normally leave that up to the OS itself. However, in most cases, there are a few tasks that must be performed to get the system to the state expected by the OS, and those tasks are performed by the loader code.
- 53. 1.6 SYSTEM CALLS 17 1.6 System Calls : The final topic covered as part of this introduction is the connection between applications and the operating system. Almost universally, this takes place through system calls. Conceptually, the system call is a mechanism by which a process can request one of the services mentioned in this chapter from the operating system. 1.6.1 Example System Calls While we discuss a number of examples of system calls in later chapters, we give a few from the example of the UNIX operating system here: e fork(): creates a new process that is a copy of the existing one e exit( ): terminates the requesting process e open(): opens a file for reading and/or writing e read(): retrieves data from a file or device e write(): puts data to a file or device Note how each of these system calls corresponds to one of the system services that are described in Section 1.2. As with many systems, UNIX system calls are used in the same way as ordinary library functions. This is illustrated in Example 1.2. Example 1.2: Using System Calls In order to illustrate their use, consider a sample use of some system calls. Suppose we want to read the header from a file. A function to do this, coded in the C language, might look like: int load_hdr(char «name,char *buf) { int fd; fd = open(name,O_RDONLY ); if (fd < 0) return (fd); n = read (fd, buf ,HDR_SIZE); close (fd); return(7n); } In this example, we start by opening the file for reading. The open() system call returns an integer file descriptor which we then use for the other calls related to that file. In the read() system call, we request that the OS copy data from a file into the memory space at the location pointed to by buf. The number of bytes requested is given by HDR_SIZE and fd identifies what file we want to read. Upon completion, the system call returns
- 54. 18 CHAPTER 1 INTRODUCTION TO OPERATING SYSTEMS (and we assign to the variable n) the number of bytes actually read. If the OS detects an error and is unable to read any data, then it returns a —1 and the global variable errno is set to indicate which error was detected. While every system defines its own conventions, this example illustrates the common features. First, we need a mechanism to specify which service we are requesting. Here, it is the call to a function called read() that specifies the requested service. Second, most requests require that the process making the request provide some parameters. In this ex- ample, the parameters are passed (initially) through the normal function call mechanism. Finally, nearly all system calls produce some results. At the very least, they produce a status indicating whether the request was successful. In this example, the result comes back to the requesting process using the normal function return mechanism. 1.6.2 System Call Mechanism There are a variety of ways in which the system call mechanism can be implemented, but we describe a typical one here. Notice that the examples we give in the previous subsection are all shown as function calls in a high-level language. Normally, the compiler doesn’t know anything special about system calls as opposed to normal function calls. We can get away with this because the libraries we link to have small ordinary functions for each of the system calls. These small stub functions don’t usually do much more than set up the system call parameters in a well-defined way and then switch control to the operating system. The transfer of control is often done through some type of software interrupt (often called a trap) instruction. These special instructions cause the CPU to save the current state of the machine and transfer control to a function in the operating system. They are like a cross between an ordinary subroutine call instruction and a hardware interrupt. Upon receiving the transfer of control, the operating system will usually suspend the requesting process. At some later time when the request can be fulfilled, the requesting process is resumed with the system call results returned in a well-defined way. 1.7 Summary Without software, a computer is just a static lump of silicon. The operating system is the base level of software on which applications run. It is responsible for managing and allocating the system hardware, including the CPU, physical memory, and I/O devices. The operating system also provides support for additional functions such as file systems and network protocols. In providing these functions, we can look at the operating system as a manager of the system’s resources, as a provider of services, and as defining a virtual machine. There are several ways in which we can put the pieces together to build a complete operating system. Some systems are structured as a conventional monolithic program. Others follow a layered design. Still others are based on microkernels and some are virtual machine designs. Regardless of how the system is structured, it must be loaded into memory by some form of boot loader. After the system is loaded and running, it is ready to accept service requests from processes through the system call mechanism.
- 55. Random documents with unrelated content Scribd suggests to you:
- 56. Joseph examined these beautiful things and was glad that the Lord had entrusted them to him, but he felt, too, that it was a great responsibility. He had learned much during the past four years and knew that the possession of the plates would not increase his worldly pleasures. He placed the treasures under his coat and, full of determination to protect them, he set out for home. On the way wicked men tried to rob him; they struck him with a heavy club; but Joseph was a tall, strong man and a swift runner, and he escaped. They chased him almost to his father's house without overtaking him, although he was handicapped by the great weight that he carried.
- 57. CHAPTER VI. 1827-28. PERSECUTION—MARTIN HARRIS COMES TO JOSEPH'S AID—ANTHON FULFILLS A PROPHECY—MARTIN BECOMES SCRIBE—STRANGE BOOK- WRITERS. The spirit of lying, robbery, and murder is awful when it comes upon men, for it makes them seek to destroy the truth and to hinder the work of God. Mobs filled with this spirit were aroused against Joseph. They continually sought to steal the holy plates, and in doing this they would willingly have murdered him, but he was very careful and the Lord helped him. Ministers, who ought to have been teaching the people to be honest and pure, were most prominent in spreading lies and stirring up hate against the young Prophet. He had never harmed them, but he had been brave enough to declare that the Lord had spoken to him, though the world turned his enemy. Moroni had directed Joseph to translate the record, but his enemies were so cunning and so violent that he had to hide it to keep it out of their hands. At one time they would suddenly break into the house and tear up the hearth, at another they would climb into the attic and search; but in every case Joseph had removed the treasure before they came, and they hunted in vain. This of course kept him from translating, and at length he decided that he would leave Manchester and go to his wife's home in Pennsylvania, hoping to be able to work there in peace. Joseph had received low wages while working for Mr. Stoal and the year of farming had not brought him much money. But Harmony, where Mr. Hale lived, was about one hundred and fifty miles from Manchester and it was impossible for him to move without aid.
- 58. Sometimes the Lord inspires men to do strange things to help His work. Martin Harris, a well-to-do farmer, came to Joseph at this time, and in spite of all the lies he had heard, gave him fifty dollars. Joseph was now able to reach Pennsylvania. On the way, there was some excitement, for twice men came with search warrants and hunted for the plates. These were hidden in a barrel of beans and the men who would have liked to steal them failed. It was December when he came to the home of his father-in-law, and for two months he worked at copying the characters from the plates to sheets of paper, and writing beneath the translation made by means of the Urim and Thummim. In February, 1828, Martin Harris came down to Pennsylvania and Joseph gave him the sheets. Martin took them to New York City to find out whether the characters would be accepted as real by learned men. He showed them first to Prof. Charles Anthon of Columbia College. Mr. Anthon examined them carefully and said that the translation was correct and the best he had ever seen of Egyptian characters. He wrote a certificate to this effect, and gave it to Martin. He asked how the young man happened to find the plates, and when Martin said that an angel had shown him where they lay, he asked for the certificate again. Martin returned it and Mr. Anthon tore it to pieces, saying that there was no such thing as the ministering of angels. Although Mr. Anthon was too cowardly to let his name go before the public connected with what an angel was said to have revealed, yet he would have liked to obtain worldly praise by translating the record himself, and asked Martin to bring it to him. When told that this could not be done and that part of it was sealed, he replied, "I cannot read a sealed book." If you read the twenty-ninth chapter of Isaiah you will find that the prophet spoke of this circumstance two thousand five hundred years ago. Martin Harris carried the characters to Dr. Mitchell, another learned man, and he also said they were genuine. This convinced Martin, and he returned to Pennsylvania. He now arranged with Joseph to become his scribe and to write at his dictation, but first it was necessary to return home that he might prepare for a long stay. He came back to Harmony about the middle of April ready to work.
- 59. Joseph had very little education at this time; he could not spell so well as the ordinary school-boy can now; his time had been spent in work, and he had had few opportunities to learn. But now a book lay before him written long ago in a strange tongue and he was to translate it into English. Isaiah said that the sealed book should be given to one that was not learned, and certainly it had now been done. Joseph could not take honor to himself as the translator of it; he was only a humble instrument in the hands of God in bringing it forth. When Martin came the second time he immediately began service with Joseph, and no writer of books ever worked as did they. A screen divided the room in which they sat. On one side of this was the young Prophet—a tall, manly fellow, dressed in working clothes that had seen long use, his serious, handsome face bronzed by the sun and wind, and his hands hardened by toil. Before him lay a pile of golden leaves in book form, worth a fabulous sum from a worldly standpoint, and yet too sacred to be looked on even, except by the one chosen to bring them forth. Before his eyes he held large spectacles with thick, bright stones as glasses. Slowly he read aloud in simple English from the strange figures on the metal pages. On the other side sat a somewhat older man, well-dressed, but plainly a country-man, busily writing down the words that were spoken.
- 60. CHAPTER VII. 1828-1829. MARTIN HARRIS IMPATIENT—THE MANUSCRIPT LOST—GOD'S WISDOM SHOWN—JOSEPH REPENTS—SLOW PROGRESS OF TRANSLATION. Joseph and Martin worked together until the translation covered one hundred and sixteen pages of foolscap paper. Martin Harris was not a patient man, and it occurred to him that he would like to show his friends what he had written without waiting until the work was completed. Joseph refused to permit this, for the work was not done to gratify curiosity; but Martin teased and Joseph inquired of the Lord. The answer forbade Joseph's letting the manuscript go, but Martin was not satisfied and worried him until he asked again. Once more the Lord refused, and for a time Martin worked along without complaining; but his wife and other members of his family desired to see what was written of the new book, and he again induced Joseph to ask. It was wrong for the Prophet to give way after the Lord had twice answered him, but Martin made so many promises to be careful that there seemed little reason for fearing injury to the manuscript. The last time the Lord replied that Martin might take the writings on condition that he would show them only to five persons, his wife, father and mother, brother and sister-in- law. Joseph, too, was held responsible for them. With very solemn vows Martin Harris covenanted to guard the writings and return them, but he was tempted to show them to other persons and they were stolen from him. They fell into the hands of evil men and neither he nor Joseph ever saw them again. The Urim and Thummim had been taken from the Prophet because he displeased the Lord in asking so often about the writings. When Martin had
- 61. gone from Harmony after two months of work as scribe, Joseph went to his father's home on a visit, being unable to go on with the work. He soon returned from Manchester and the Urim and Thummim was given back to him. He was permitted to keep it while the Lord gave him a revelation, and then it with the plates was taken away. Do not think that the Lord could not have given the revelation without the Urim and Thummim. In later years Joseph did not use it, but he was still young and the Lord perhaps thought it best to make him feel dependent by not communing openly at all times with him. The revelation was a rebuke to him for his weakness and a warning that though he had been much favored he would still be rejected if he were not faithful and humble. The Lord told him that the work should still go on, even though he proved faithless. Joseph's sensitive spirit was deeply hurt and he humbly repented of what he had done. The plates and the Urim and Thummim were given back to him again and he was directed to continue his labors. It was revealed that if he should re- translate what Martin Harris had lost, those who had stolen the manuscript would change it in places and would deceive the world by saying that Joseph could not translate twice alike, and therefore his work was not of God. But though Satan had laid a cunning plot, the wisdom of God triumphed. If you have read the Book of Mormon you have perhaps noticed a difference in the books of First Nephi, Second Nephi, Jacob, Enos, Jarom and Omni, from what follows. If you have not read this beautiful record, remember to notice the difference when you do, and you will see one sign of the complete wisdom and forethought of God. These books were written on the small plates of Nephi, and when Mormon, the father of Moroni, found them, he joined them to the abridgment he had made of the larger plates. The two sets of plates cover the same period of history, but the larger set deals more with government and the political affairs, while the smaller is rather a record of the dealings of the Lord with the people. Nephi hardly knew why he was commanded by the Lord to make the smaller plates and write upon them, but he obeyed. Moroni tells us he did not know why he was moved upon to add them to his abridgment. But we
- 62. now see the purpose of the Lord in it. The translation that Martin Harris lost was from Mormon's abridgment of the larger plates. Joseph was commanded to translate the same part from the smaller plates, and thus Satan's plan to deceive could not be used. This change makes the Book of Moroni more valuable, too, because on the smaller plates were written many choice prophecies and revelations that Mormon did not give in the abridgment. Joseph did not at once begin to translate, but for a time worked on a small farm he had bought from his wife's father, Isaac Hale. He received a number of important revelations about this time for the comfort and instruction of himself and of others who came to him. When he began to translate again the work went on very slowly for he had no one to write for him regularly. Sometimes his wife Emma could spare time and a little progress was made. But Joseph and Emma had lost their firstborn child, a son, soon after his birth in July 1828, and the mother through grief and poor health could give but little assistance in the work. This state of affairs continued until April 1829.
- 63. CHAPTER VIII. 1829. OLIVER COWDERY BECOMES SCRIBE —JOSEPH AND OLIVER PRAY FOR NEW LIGHT—THE PRIESTHOOD RESTORED—THE FIRST BAPTISMS— KINDNESS OF JOSEPH KNIGHT. Joseph was now twenty-three years old, and his life up to this time had been in a sense only a preparation for his work. He had held the plates for a year and a half and though he had studied them and had translated a considerable part yet through Martin Harris' sin he was still at the beginning of the book. But that time had been valuable for him, though he had little to show for it. He had learned what the displeasure of the Lord means and, though forgiven, he had been taught a lesson that he never forgot. Still he had been true to his trust in guarding the plates and no mortal eyes except his own had looked upon them. As the sun was setting on Sunday, April 5, 1829, a young man came into Harmony and sought Joseph for the purpose of making his acquaintance and of helping him. This man was Oliver Cowdery, who during the past winter had taught school at Manchester and, as teachers in country schools used to do, he boarded around at the students' homes. In these visits he came to live with the family of Joseph Smith, Senior, and there he heard of the younger Joseph and his work. He was at first struck by the strangeness of it all, and then prayed seriously to God to learn whether He really had revealed Himself in this day. The Holy Ghost manifested to him that Joseph had assuredly been visited by celestial beings and that he was called to aid the young Prophet in his work. When school had closed, therefore, Oliver came to Pennsylvania, and two days after meeting Joseph, the young men set themselves earnestly to the
- 64. work of translation. There were few interruptions, and as Oliver was used to writing, the progress was rapid. Sometimes they found things in the Book of Mormon or the Bible that they did not understand, although they talked them over together and studied them ever so hard, and when this happened they asked the Lord to explain these matters to them. Sometimes they prayed just as we do, and sometimes Joseph put on the Urim and Thummim besides; but the Lord always answered them and showed them what they did not understand. When tired of writing they would often go for a walk in the woods or down to the river for recreation and healthful exercise. A favorite pastime was to throw stones into the stream. Joseph especially was very fond of jumping and wrestling, and was expert at both. It is said that he could walk under a pole—he was six feet tall—and then, taking a step or two back, jump over it. He was a noted wrestler, and in later life even, he often enjoyed a vigorous bout. Though his life was a most busy one he still found time to keep his body strong and healthy and to relax his mind by athletic practice. About a month after beginning work, Joseph translated from the plates a passage that spoke of baptism. It said that it is necessary to be baptized in order that a person's sins may be washed away and forgiven. Neither Joseph nor Oliver had been forgiven of past sins by baptism, and after talking over the matter earnestly, on the fifteenth of May, 1829, they went into the woods to pray for light. While they were kneeling a voice from the midst of heaven bade them have peace, then the veil parted and John the Baptist came down before them. This is the same brave prophet who preached repentance and the coming of the Savior, in the wilderness of Judea and baptized Him in Jordan. John was beheaded while in prison by Herod, but now he came quickened and clothed with glory. He calmed them with his gentle yet thrilling voice, telling them he was their fellow-servant and acting under the direction of Peter, James and John. He laid his hands upon their heads and ordained them to the Aaronic Priesthood, which he represented in life. His words were: "Upon you my fellow servants, in the name of Messiah, I confer the priesthood of Aaron, which holds the keys of the ministering of angels and of the gospel of repentance and of baptism by immersion for the
- 65. remission of sins; and this shall never again be taken from the earth until the sons of Levi do offer again an offering unto the Lord in righteousness." John then directed Joseph to baptize Oliver and that Oliver should baptize Joseph; after this in the same way they should ordain each other to the Aaronic Priesthood. He said that they must not lay on hands for the gift of the Holy Ghost as that was not the power of the Priesthood of Aaron. Later the Melchizedek Priesthood would be given them and then they could lay on hands and perform other holy offices. There was a river nearby and Joseph and Oliver went into it together, prepared to perform the sacred ordinance. It was a strange sight on earth, and no doubt the hosts of heaven were glad, for since the righteous Nephites no man had been cleansed from sin in the waters of baptism. Joseph seriously spoke the simple words of the ordinance and then laid Oliver beneath the water. As he drew him up, suddenly the spirit of prophecy came upon Oliver. He was filled with joy and foretold glorious things that were about to come to pass. Oliver then baptized Joseph and the Holy Spirit fell in a like manner upon him. He prophesied concerning the rise of the Church and of its progress, and declared many things that were to happen in that generation. Filled with these exalted feelings, Joseph laid his hands upon Oliver's head and ordained him a Priest after the order of Aaron, and Oliver did the same to Joseph. They already held the Priesthood, because that was given by John, but they re-ordained each other as a pattern for others, since the Priesthood was to be conferred in the future after baptism. From this time on the minds of the young men were enlightened and they understood things that had been mysteries before. Persecution had begun, and for a time they said nothing about what had taken place; but soon they began explaining the scriptures to all who would listen. Joseph's brother Samuel, who came on a visit at this time, was shown the translation already made, and heard the testimony of Joseph and Oliver. After a time he became partially converted and went alone to pray and learn from the Lord whether the work was true. A strong testimony was given
- 66. him, and soon after Oliver baptized him. On coming out of the water he too began to prophesy remarkable things, as Oliver and Joseph had done. Samuel returned home and Hyrum came to Harmony. He heard the truth and believed. A very kind service was done the Prophet at this time by Joseph Knight, an old gentleman living in Broome County, New York. Now and at other times, he brought a load of provisions in order that Joseph and Oliver might keep on translating. But though supplied with food and protected from violence by the family of Isaac Hale, still persecution grew very severe against them and it seemed necessary to move from Harmony, if they wished to work in peace.
- 67. CHAPTER IX. 1829. DAVID WHITMER TAKES THE PROPHET TO FAYETTE—MANY BELIEVE AND ARE BAPTIZED— ELEVEN WITNESSES SEE THE PLATES AND BEAR RECORD—THE HIGHER PRIESTHOOD RESTORED—THE TRANSLATION FINISHED. Early in June, 1829, a young man drove up to Joseph's door after two days of hard traveling. He said that he had come from Fayette, Seneca Co., New York, one hundred and fifty miles away, for the purpose of carrying the Prophet and his companion to Fayette if they wished to go. He was David Whitmer, son of Peter Whitmer, and his father invited Joseph to come to their home. They offered him protection and to provide for his wants while he was working at the translation. Joseph accepted the invitation and, leaving Emma with her father, he and Oliver departed with David. Before setting out Joseph asked the Lord how he should carry the plates. In answer to his prayer Moroni appeared and took them from him, promising to return them again. When he reached Fayette the angel visited him in Mr. Whitmer's garden and gave them over to him. The translation continued very rapidly, for when Oliver grew tired, David or his brother John was ready to write at the Prophet's dictation. When not translating, Joseph and Oliver spent their time in teaching those who came to listen and in explaining what the Lord had revealed to them. There were many serious persons who wished to hear the truth. David Whitmer had been remarkably aided that he might hasten to bring Joseph to
- 68. Fayette. Three strange men were seen scattering the plaster that David had put in a heap upon one of his fields to fertilize it, and they did it with more than human skill and speed. In harrowing in wheat on another field David had done in one day more than he could usually have done in two or three days. Many in the neighborhood hearing of this were impressed that the Lord had helped him in bringing the two young men and believed that they were His servants. When any person became convinced that the work was divine and desired to be baptized, that ordinance was performed. Joseph soon had the pleasure of baptizing his brother Hyrum and David Whitmer, and at the same time Oliver baptized Peter Whitmer, Junior. Soon there were so many believers that baptisms were performed nearly every day in Seneca lake, a beautiful body of water lying on the western border of Seneca County. While at work on the translation it was learned that three persons should be shown the sacred plates in order that their testimony might be given to the world. Oliver Cowdery, David Whitmer and Martin Harris begged Joseph to ask the Lord if they could not be the ones. Joseph did this during the month of June, 1829, and the Lord answered that if they trusted in His words with full purpose of heart they should be shown the plates, the breastplate, Urim and Thummim, sword of Laban and the Liahona, or compass, given to Lehi in the wilderness. Soon after they all went into the woods to pray that the Lord would show the plates, which Joseph had given up for the time to the Angel Moroni. The four men kneeled down and Joseph offered a prayer, then the others in turn prayed, but no answer came. Joseph began again and the others followed but though they prayed with fervor yet they failed to receive any manifestation. Before beginning again Martin Harris said he believed he was the cause of the failure. He offered to go aside and pray alone. Martin had spoken the truth, for soon after he withdrew, a light of surpassing fairness came down from heaven and within it stood the angel holding the golden plates. He turned the leaves and the characters engraved thereon were illumined so that the witnesses saw them plainly. They also heard the voice of the Lord declaring that the plates before them were
- 69. revealed by God and had been translated by His power. They were commanded to bear record that the translation was correct. When the vision passed away Joseph sought Martin Harris. He found him, humbled by this rebuke for his past wickedness and praying with his whole heart for forgiveness and for the privilege of viewing the record. Joseph joined him in prayer and soon the angel again appeared and the whole vision was repeated. Martin had never beheld a spiritual sight before and he could not long bear the glory before him, but he was filled with joy and shouted hosannah to God. The three men who had been chosen as witnesses drew up and signed a statement, which is now printed in the fore part of the Book of Mormon. They testified to all the world that they had seen an angel holding the plates and heard the voice of God declaring that the translation was correct. Oliver Cowdery, the first signer, went on missions and did much good, but he lost his virtue and fell. In 1838 he was cut off from the Church. David Whitmer lost his standing at the same time and Martin Harris in the same year. For nine years Oliver Cowdery was separated from the Church and for thirty- three years Martin Harris remained away, but both were finally rebaptized and died in the Church. David Whitmer never came back, but he and his fellow-witnesses affirmed time after time that they had really seen the angel and beheld the golden plates. The Prophet was permitted to show the record to eight other persons as an additional testimony. They were Christian, Jacob and John Whitmer and Peter Whitmer, Jun., Hiram Page, Joseph Smith, Sen., and his sons Hyrum and Samuel H. Smith. These men handled the plates and seriously judged them to be of gold and engraved with ancient work. They were without exception unflinching in their testimony that the Book of Mormon is true. When John the Baptist visited Joseph and Oliver to give them the Aaronic Priesthood he promised that the Priesthood of Melchizedek would later be conferred upon them. They became very desirous to receive this and made it a matter of prayer. As they were once asking the Lord about it they heard His voice directing them to ordain each other, but not until they were accepted as spiritual teachers by those already baptized. Sometime after this, during the month of June, 1829, Peter, James and John appeared to
- 70. them and conferred upon them the holy Priesthood. These three had been chosen by Jesus Christ when He lived on the earth to preside over the Priesthood and it was their office to restore it when the Lord chose to permit men on the earth again to hold it. The work of translation was now drawing to an end, and a contract was made with Egbert B. Grandin of Palmyra to print five thousand copies. In August, 1829, the work of printing began. The copy used was not the original manuscript, but the whole was rewritten and Joseph preserved the original. Three thousand dollars was the price agreed on and Martin Harris gave security for its payment. In March, 1830, the book was issued to the world. When the work was finished Joseph with Oliver took the sacred treasures to the Hill Cumorah. They did not, however, replace them in the stone box, but, when they reached the hill the earth opened and they walked into a spacious room. They laid the plates down on a table, upon which stood many other plates, and left them to be guarded by the angel. Treasure seekers have searched for them, the stone box has been torn away, but they have been sought in vain and they will remain hidden until the Lord's own due time. Oliver Cowdery was left by Joseph to watch over the work of printing and the Prophet was free to visit his wife at Harmony. It was, however, a busy winter for him, for he received many revelations concerning the organization of the Church, and he spent much time in declaring the truth to all who would listen.
- 71. CHAPTER X. 1830. THE CHURCH ORGANIZED—JOSEPH ACCEPTED AS LEADER—THE HOLY GHOST CONFERRED—JOSEPH CASTS THE DEVIL FROM NEWEL KNIGHT— THE FIRST CONFERENCE. On the sixth day of April, in the year eighteen hundred and thirty, was organized at the home of Peter Whitmer in Fayette, Seneca county, New York, the Church of Jesus Christ of Latter-day Saints. Six men made the organization, and their names are Joseph Smith, Jr., Oliver Cowdery, Hyrum Smith, Peter Whitmer, Jr., Samuel H. Smith and David Whitmer. It was a humble beginning for the Church of Jesus Christ, as was His beginning humble when He came upon the earth. At that time mighty mansions and gorgeous palaces stood as the dwelling places of royalty, but the Great King was born where cattle and beasts of burden were housed. Now splendid churches and magnificent cathedrals stood as places of worship, but Christ's Church was organized and the mighty work of salvation begun in a house of logs in an obscure village and by country men of little worldly learning. But the Spirit of God and the holy Priesthood were there. Jesus had revealed the manner of organization and the day, and had commanded that it be called after Him since it was His Church. The six men had been forgiven of sin through baptism. Under these circumstances the rudeness of the surroundings was of little account. The meeting opened by prayer. Joseph and Oliver were first accepted as spiritual teachers, and then Joseph laid his hands on Oliver's head and ordained him an Elder in the Church of Jesus Christ of Latter-day Saints.
- 72. Oliver ordained Joseph to the same office, and they administered the sacrament. They now possessed the authority to confer the Holy Ghost, and they did so by laying their hands upon the heads of their companions, and at the same time they confirmed them members of the Church. As on the day of Pentecost when the Holy Ghost, coming down from Heaven like cloven tongues of fire, gave to the Apostles new understanding, so now the minds of those who received it were filled with light. Some prophesied, and all rejoiced and praised God with thankful hearts. To Joseph was given a revelation calling him to the leadership and Oliver to the place of second Elder and preacher in the Church and commanding the members to give Joseph their obedience. The Spirit also directed Joseph and Oliver to call out and ordain some of the members to different offices in the Priesthood. A number of persons besides the six members were present at the meeting on the sixth of April and they soon asked that they might be baptized and received into the Church. Joseph's father and mother and Martin Harris were among these. On the following Sunday, April 11th, Oliver Cowdery preached the first sermon of this dispensation of the Gospel. The meeting was again at Peter Whitmer's house and many were present. Six more desired baptism, and Oliver performed the ordinance in Seneca Lake. A week later he baptized seven others in the same place. Soon after the Church was organized the Prophet set out to visit the family of Joseph Knight, at Colesville, Broome county. You remember that Mr. Knight had helped Joseph, and the work, a year before by bringing provisions to Harmony. In gratitude Joseph now carried to him what is better than food in the greatest hunger—the Gospel. He was very kindly received and had the privilege of holding a number of meetings. Many honest souls became interested and sought for testimonies. Newel Knight, the son of Joseph Knight, was one of these and had promised the Prophet that he would pray in meeting. When the time came, however, he was unwilling, and said that he would pray first in secret. Joseph could not induce him to call upon the Lord there. Newel came back from the woods next morning, where he had retired, very much distressed. He had tried to pray, but he felt he had done wrong to refuse when called
- 73. upon and now it was very hard to ask the Lord for light. He grew ill and sent his wife for Joseph. When the Prophet reached the house Newel was in a frightful condition. His features and limbs were twisted out of shape and he was being thrown violently around the room. A number of persons had come, but they knew not what to do. Joseph at length caught his hand and Newel immediately spoke and begged the Prophet to cast the devil out of him. Joseph rebuked the evil spirit, and in the name of Jesus Christ commanded it to depart. Newel was instantly freed from it, and declared that he saw the devil come out of him and disappear. He was in his natural state only for a moment. Another power seized him and raised him to the ceiling where he remained for a time unconscious. But this was the Spirit of God, not of the devil, and when he came to himself he told of a heavenly vision of unspeakable beauty that had been given him. Those present in the room were astonished. They had seen the destroying power of Satan and the enlightening power of God. They had beheld a miracle such as the world had not seen since the time of the Apostles, and they were convinced that Joseph held the same power as did they of old. Joseph soon went back to Fayette, and continued his teaching among the people. On the first day of June, 1830, the first conference of the Church was held, at the Whitmer home. It opened by singing and prayer and the sacrament was administered. A number of confirmations were made and the Holy Ghost again descended upon the Saints. The spirit of prophecy rested upon some, while others beheld glorious visions and sank to the floor overcome. Newel Knight, who had journeyed to Fayette shortly before and been baptized by David Whitmer, had the curtain of heaven again drawn aside. He looked upon his Redeemer Jesus sitting beside the Eternal Father, and he realized that some day it would be his blessed privilege to come into their presence and dwell forever. The future was unfolded before him and he saw the progress of God's Kingdom on earth.
- 74. Much instruction was given the Saints, and they were filled with gratitude for what they had seen and heard. Their hearts overflowed with joy and love and they felt eager to press forward in the work. Once more believers came forth and requested baptism, and David Whitmer was appointed by the Prophet to perform it.
- 75. CHAPTER XI. 1830. BAPTISMS AT COLESVILLE—JOSEPH ARRESTED—DAVIDSON AND REID ON THE DEFENSE—SUFFERING LIKE THE MASTER—NARROW ESCAPE FROM MOBS. When the conference of June 1st, 1830, was over Joseph went to his home at Harmony after a somewhat long absence. He had no time, however, to settle down and rest; he was still needed in the work of our blessed Master, and so taking his wife with him he set out for Colesville accompanied by Oliver Cowdery, David and John Whitmer. Many persons were there who had faith in the Lord and in His work and had repented of past wrong doing. They now desired to be cleansed from sin by baptism, and to be given the Holy Ghost that they might be numbered with the Saints. It was Joseph's intention to have the baptism performed on Sunday, and on Saturday afternoon he and the others placed a dam across a stream near Mr. Knight's house so that the water would be deep enough. The baptizing had to be put off, however, for during the night the dam was torn away by a mob that had been aroused by the ministers of the neighborhood. It would be interesting to know the texts used that Sunday by these pastors who were hired to lead their flocks in Godly and peaceful paths. Monday morning early the dam was again built before the mob was astir, and Oliver Cowdery baptized thirteen persons. Among these was Emma Smith, the Prophet's wife. It was a joyful occasion for Joseph. Before the baptizing was finished the mob had come together and begun to show an ugly spirit. Joseph and his friends retired to Mr. Knight's house. The mob
- 76. followed and tried to pick a quarrel, but the brethren would not quarrel and so these bad men had no excuse to hurt them although they would have liked to do it. A meeting was set for the evening, to confirm those baptized. The people had gathered and were just ready to commence when in walked a constable and arrested Joseph on the charge of being a disorderly person, and of setting the country in an uproar by preaching the Book of Mormon. What a charge! Joseph had held a few quiet meetings in private houses, and the uproar was not begun by him. You can imagine that the people were surprised and some, no doubt, were pretty angry, but Joseph allowed himself to be arrested quietly. He acted so like a true gentleman—he always was a gentleman—and had such an honest face and manly bearing that the officer made up his mind that he was no rascal but a true man, and straightway became his friend. And it was fortunate for Joseph that he did, because he had intended to lead the Prophet into a trap. Of course, now he changed his mind and told him that the arrest was only a trick to get him away from his friends and let him fall into the hands of the mob, which was lying in wait for him on the road. The constable determined to try a trick of his own on the mob, and they set out together in a light wagon. They had not gone very far before they came upon a crowd of evil-looking men, who gathered about to seize Joseph as soon as the wagon stopped. The constable drove in among them and they awaited his signal. Suddenly he seized his whip and gave his horse a cut and before the ruffians could stir the wagon was just out of their reach. Then began a great race—horse against man, and the horse was getting the best of it. The mob, though they ran as fast as they could, were being left behind, and Joseph and the officer were breathing more easily, when suddenly off came the wagon-wheel. What a plight they were in! If they had stopped to say bad words about their luck they would probably have been caught, for the mob were racing down the road like mad, but they did not swear, they jumped from the wagon, replaced the wheel, fastened it, and away they sped again just in time to escape.
- 77. They continued to South Bainbridge in the adjoining county and here secured a room in a tavern for the night. The constable gave Joseph the bed while he slept with his feet against the door with a loaded musket at his side. They were not disturbed. Next day the Prophet came as prisoner into court. It was the first time that he had ever been tried on any charge. Many times afterwards he was taken before courts for trial, and yet in no case was he ever found guilty. But though he suffered so much from wicked persecutors he never refused to submit himself to the law. When the constable had come and taken Joseph away from the meeting, it broke up, and Joseph Knight went to two of his neighbors, James Davidson and John Reid to engage them to defend the Prophet in court. These men were honorable, intelligent farmers who understood well the principles of justice and the laws of the land. Though they had never seen Joseph and were in no way connected with the Church they consented to take his case in spite of the violent prejudice against him. Mr. Reid afterwards said that when asked he was at first unwilling on account of other work, but before he could refuse he heard a low voice say, "You must go to deliver the Lord's anointed!" The messenger had not spoken and had not heard the voice, and Mr. Reid felt that he had received instruction from heaven. He willingly took the case, feeling sure of success. The prosecution was carried on by a Presbyterian named Seymour, and he tried by false witnesses to win the case, but Joseph's lawyers pleaded well, and the judge set him free. He was immediately arrested again by another constable and taken back to Colesville, Broome county, to be tried there. They stayed over night at a tavern, and during the evening, the officer invited bad men in to join him in abusing the Prophet. What they did there would have shocked a decent heathen, Joseph was a helpless prisoner in the hands of an officer of the law and there was no reason for thinking him guilty of any crime. Yet that coward officer with his associates spit upon him, and cursed him, and then pointing their fingers at him told him to prophesy. You all have heard how Judas led the multitude against Jesus as he prayed on the mount of Olives, and how they took Him
- 78. to the house of Caiaphas the high priest to bring false witness against Him. And there they buffeted Him, and spit upon Him, and told Him to prophesy. Joseph thought of this, and though his sensitive nature must have sickened at the treatment, yet he remembered that he was only servant and that the Master had suffered thus. In both cases it was the same low, cowardly spirit of Satan, the spirit that always seeks to pollute the pure and unprotected. The Prophet had eaten nothing since morning and was hungry and tired. He asked for food, and the constable gave him a few crusts of bread. He then offered security for his appearance and asked that he might be allowed to spend the night at home. This was refused. He was compelled to sleep against the wall and the constable took away all chance of comfort by lying at his side and holding him all night long. Next day Joseph was again tried, and the same lawyers and witnesses were present to prosecute him, as on the day before. He was glad to find there also the men who had so ably defended him. The evidence against the Prophet was shown either to be false or to have no bearing on the subject. Lawyer Seymour sought to prejudice the court by a violent speech, but Mr. Davidson and Mr. Reid spoke with such astonishing power in his behalf that the accusers cowered before them. They each thanked God that they were permitted to defend a man whose character was so free from guilt. So effective was the defense in this case that many who had wished the Prophet harm now became his friends. Even the constable who had been so unmanly, asked his pardon and offered him aid. The officer told him that the mob had gathered and was determined to tar and feather Joseph and ride him on a rail, since he could not be injured legally. He led the Prophet out by a secret way and Joseph escaped. Next day with his wife he returned to his home in Harmony. Those baptized at Colesville had not yet been confirmed members of the Church, because such a bad, un-American spirit had taken hold of the people there that Joseph and his friends hardly dared to be found in the neighborhood for fear of being hurt or killed. After a little while, however, he and Oliver came on foot from Harmony, but they had no sooner reached Mr. Knight's house than their enemies, learning they were there, formed a mob and came to capture them. Now what should the two men have done in
- 79. such a position? They might have remained, determined to have their rights, and with the help of their friends fought the mob. They were not afraid, Oliver was brave, and Joseph Smith did not know what fear was. But they were ministers of peace, and peace could be had only by going away, and they went. They did not stop for food or drink, but hurried to escape, for their enemies were following like a pack of bloodhounds. Several times they were nearly caught, but they were strong men and outran their pursuers. They traveled all night and reached home in the morning, pretty thoroughly tired out. In July, 1830, Oliver Cowdery left Joseph and went to Fayette to labor there. In his place, as scribe to the Prophet, came John Whitmer and Joseph with his help began to re-write and arrange the revelations that he had received up to this time. Many had been given, and it was necessary that they be kept for the use of the Church in the future.
- 80. CHAPTER XII. 1830. FIGHTING THE EVIL ONE—THE MOB BLINDED—PRESIDENT ALONE TO RECEIVE REVELATION FOR THE CHURCH—FIRST MISSIONARY MOVEMENT—WORKING IN THE WEST. When Joseph first visited the hill Cumorah the Lord let him look upon the kingdom of heaven and upon the kingdom of hell. He saw the powers of each, and the methods and influences that each used. This vision was of great value to him throughout life. The contrast made him desire with all his heart to reach heaven and kept him on the alert at all times to escape hell. What was also very important, it gave him a complete knowledge of the practices and weapons of Satan, the enemy of truth. All this he beheld in vision, but through the following years in real life he saw these powers of evil at work, and he had to fight against them. Thanks to the knowledge given him, to his faithfulness and to the help of the Lord, he came off victor in every engagement. He had met Satan in the thieves and murderers that tried to steal the plates, in the lying ministers that sought to blacken his character, in the violent devil that nearly destroyed Newel Knight and in the mobs that only recently attempted to capture and kill him. It was now necessary for him to meet another attack of the evil one, and it gave him more grief than any up to this time. While working with John Whitmer at Harmony, probably during the latter part of July, 1830, Joseph received a letter from Oliver, who was at Fayette, commanding him in the name of the Lord to erase part of a revelation he had received. Joseph saw that Satan was now in the flock and that Oliver had been deceived by him. He wrote asking by what authority Oliver commanded
- 81. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com