System Principles Peter Reiher Outline Administrative materials Introduction to the course Why study operating systems Basics of operating systems Administrative Issues Instructor and TAs ID: 809045
Download The PPT/PDF document "Introduction CS 111 Operating" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
IntroductionCS 111Operating System Principles Peter Reiher
Slide2OutlineAdministrative materialsIntroduction to the courseWhy study operating systems?Basics of operating systems
Slide3Administrative IssuesInstructor and TAsLoad and prerequisitesWeb site, syllabus, reading, and lecturesQuizzes, exams, homework, projectsGradingAcademic honesty
Slide4Instructor: Peter ReiherUCLA Computer Science department faculty memberLong history of research in operating systemsEmail: reiher@cs.ucla.eduOffice: 3532F Boelter HallOffice hours: TTh 1-2Often available at other times
Slide5My OS BackgroundMy Ph.D. dissertation was on the Locus operating systemMuch research on file systemsFicus, Rumor, Truffles, ConquestResearch on OS security issuesData Tethers
Slide6TAsMuhammad Mehditaqi@cs.ucla.eduDiyu Zhouzhoudiyu@cs.ucla.eduZhaoxing Buzbu@cs.ucla.edu Jungbeom Leejungbeol@g.ucla.edu Lab sessions:Lab 1A, Fridays 10-12 AM,
Boelter
9436
Lab 1B, Fridays 12- 2 PM,
Humants
169
Lab 1C, Fridays 2-4 PM, Rolfe 3134
Lab 1D, Fridays 4-6 PM, Bunche 2160
Office hours to be announced
Slide7Instructor/TA Division of ResponsibilitiesInstructor handles all lectures, readings, and testsAsk me about issues related to theseTAs handle projectsAsk them about issues related to theseGenerally, instructor won’t be involved with project issuesSo direct those questions to the TAs
Slide8Web SiteSome materials found on CCLE web siteLike quizzesMost materials here:http://www.lasr.cs.ucla.edu/classes/111_fall16What’s there:Schedules for reading, lectures, exams, projectsCopies of lecture slides (Powerpoint and PDF)AnnouncementsSample midterm and final problems
Slide9Prerequisite Subject KnowledgeCS 32 programmingObjects, data structures, queues, stacks, tables, treesCS 33 systems programmingAssembly language, registers, memoryLinkage conventions, stack frames, register savingCS 35L Software Construction LaboratoryUseful software tools for systems programmingIf you haven’t taken these classes, expect to have a hard time in 111
Slide10Course FormatTwo weekly reading assignmentsMostly from the primary textSome supplementary materials available on webTwo weekly lecturesWith online quizzes before the lecturesFour (10-25 hour) individual projectsExploring and exploiting OS featuresPlus one warm-up project
A midterm and a final exam
Slide11Course LoadReputation: THE hardest undergrad CS classFast pace through much non-trivial materialExpectations you should havelectures 4-6 hours/weekreading 3-6 hours/weekprojects 3-20 hours/weekexam study 5-15 hours (twice)Keeping up (week by week) is criticalCatching up is extremely difficult
Slide12Primary Text for CourseRemzi and Andrea Arpaci-Dusseau: Operating Systems: Three Easy PiecesFreely available on line at http://pages.cs.wisc.edu/~remzi/OSTEP/Supplementary readings from Saltzer and Kaashoek: Principles of Computer Systems DesignFree on line athttp://www.sciencedirect.com/science/book/9780123749574Only on-campus or through the UCLA VPN
Supplemented with web-based materials
Slide13Course GradingBasis for grading:Quizzes 5%1 midterm exam 20%Final exam 30%Lab 0 5%Other labs 10% eachI do look at distribution for final gradesBut don’t use a formal curveAll scores available on MyUCLAPlease check them for accuracy
Slide14Quizzes3-5 question quizzes on the assigned reading materialsMust be taken before the lectureNot intended to be hard questionsIF you’ve read the assigned materials
Slide15Midterm ExaminationWhen: Second lecture of the 5th week (in class section, Tuesday, October 25)Scope: All lectures up to the exam dateApproximately 60% lecture, 40% textFormat:Closed book10-15 essay questions, most with short answersGoals:Test understanding of key conceptsTest ability to apply principles to practical problems
Slide16Final ExamWhen: Monday, December 5, 11:30 AM-2:30 PMScope: Entire courseFormat:6-8 hard multi-part essay questionsYou get to pick a subset of them to answerGoals:Test mastery of key conceptsTest ability to apply key concepts to real problemsUse key concepts to gain insight into new problems
Slide17Lab ProjectsFormat:1 warm-up project4 regular projectsDone individuallyGoals:Develop ability to exploit OS featuresDevelop programming/problem solving abilityPractice software project skillsLab and lecture are fairly distinctAsk instructor about tests and lectures
Ask TAs about labs
Slide18Late Assignments & Make-upsQuizzesNo late quizzes accepted, no make-upsLabsDue dates set by TAsTAs also sets policy on late assignmentsThe TAs will handle all issues related to labsAsk them, not meDon’t expect me to overrule their decisionsExamsAlternate times or make-ups only possible with prior consent of the instructorIf you miss a test, too bad
Slide19Academic HonestyIt is OK to study with friends Discussing problems helps you to understand themIt is OK to do independent research on a subjectThere are many excellent treatments out thereBut all work you submit must be your ownDo not write your lab answers with a friend
Do
not
copy
another student's work
Do
not turn in solutions
from off the web
If
you do research on a problem,
cite your sources
I decide when two assignments are too similar
And
I forward them immediately to the Dean
If
you need help, ask the instructor
Slide20Academic Honesty – ProjectsDo your own projectsIf you need additional help, ask the TAYou must design and write all your own codeDo not ask others how they solved the problemDo not copy solutions from the web, files or listingsCite any research sources you useProtect yourself
Do
not show other people your solutions
Be
careful with old listings
Slide21Academic Honesty and the InternetYou might be able to find existing answers to some of the assignments on lineRemember, if you can find it, so can weAnd we have, beforeIt IS NOT OK to copy the answers from other people’s old assignmentsPeople who tried that have been caught and referred to the Office of the Dean of StudentsANYTHING you get off the Internet must be treated as reference materialIf you use it, quote it and reference it
Slide22Introduction to the CoursePurpose of course and relationships to other coursesWhy study operating systems?Major themes & lessons in this course
Slide23What Will CS 111 Do?Build on concepts from other coursesData structures, programming languages, assembly language programming, computer architectures, ...Prepare you for advanced coursesData bases and distributed computingSecurity, fault-tolerance, high availabilityNetwork protocols, computer system modeling, queueing theoryProvide you with foundation conceptsProcesses, threads, virtual address space, filesCapabilities, synchronization, leases, deadlock
Slide24Why Study Operating Systems?Few of you will actually build OSsBut many of you will:Set up, configure, manage computer systemsWrite programs that exploit OS featuresWork with complex, distributed, parallel softwareWork with abstracted services and resourcesMany hard problems have been solved in OS contextSynchronization, security, integrity, protocols, distributed computing, dynamic resource management, ...In this class, we study these problems and their solutionsThese approaches can be applied to other areas
Slide25Why Are Operating Systems Interesting?They are extremely complexBut try to appear simple enough for everyone to useThey are very demandingThey require vision, imagination, and insightThey must have elegance and generalityThey demand meticulous attention to detailThey are held to very high standardsPerformance, correctness, robustness,Scalability, extensibility, reusabilityThey are the base we all work from
Slide26Recurring OS ThemesView services as objects and operationsBehind every object there is a data structureSeparate policy from mechanismPolicy determines what can/should be doneMechanism implements basic operations to do itMechanisms shouldn’t dictate or limit policiesPolicies must be changeable without changing mechanismsParallelism and asynchrony are powerful and vitalBut dangerous when used carelesslyPerformance and correctness are often at odds
Slide27More Recurring ThemesAn interface specification is a contractSpecifies responsibilities of producers & consumersBasis for product/release interoperabilityInterface vs. implementationAn implementation is not a specificationMany compliant implementations are possibleInappropriate dependencies cause problemsModularity and functional encapsulationComplexity hiding and appropriate abstraction
Slide28Life Lessons From Studying Operating SystemsThere Ain’t No Such Thing As A Free Lunch! (TANSTAAFL)Everything has a cost, there are always trade-offsBut there are bad, expensive lunches . . .Keep It Simple, Stupid!Avoid complex solutions, and being overly cleverBoth usually create more problems than they solveBe very clear what your goals areMake the right trade-offs, focus on the right problemsResponsible and sustainable livingUnderstand the consequences of your actionsNothing must be lost, everything must be recycledIt is all in the details
Slide29Moving on To Operating Systems . . .What is an operating system?What does an OS do?How does an OS appear to its clients?Abstracted resourcesSimplifying, generalizingSerially reusable, partitioned, sharable
Slide30What Is An Operating System?Many possible definitionsOne is:It is low level software . . .That provides better, more usable abstractions of the hardware below itTo allow easy, safe, fair use and sharing of those resources
Slide31What Does an OS Do?It manages hardware for programsAllocates hardware and manages its useEnforces controlled sharing (and privacy)Oversees execution and handles problemsIt abstracts the hardwareMakes it easier to use and improves SW portabilityOptimizes performanceIt provides new abstractions for applicationsPowerful features beyond the bare hardware
Slide32What Does An OS Look Like?A set of management & abstraction servicesInvisible, they happen behind the scenesApplications see objects and their servicesCPU supports data-types and operations bytes, shorts, longs, floats, pointers, ...add, subtract, copy, compare, indirection, ...So does an operating system, but at a higher levelfiles, processes, threads, devices, ports, ...create, destroy, read, write, signal, ...An OS extends a computerCreating a much richer virtual computing platformSupporting richer objects, more powerful operations
Slide33Where Does the OS Fit In?
Operating System
System Call Interface
Hardware
Standard
instruction set
Privileged
instruction set
(arithmetic, logical, copy, test, flow-control operations, ...
)
System Services/Libraries
Application Binary Interface
(e.g. string, random #
s
, encryption
, graphics
...)
Applications Software
(e.g. word processor, compiler,
VOIP program,
...)
Slide34Kernel Structure (artists conception)
interrupts
traps
processor
mode
memory
mapping
atomic
updates
processor
exceptions
configuration
analysis
timers
cache
mgmt
interrupts
I/O
operations
traps
processor
mode
memory
mapping
atomic
updates
context
switching
DMA
bus drivers
timers
cache
mgmt
network
class driver
serial
class driver
display
class driver
storage
class driver
stream
services
block I/O
services
processor
initialization
hot-plug
services
enclosure
management
processor abstraction
I/O abstraction
memory
allocation
memory
segments
thread
dispatching
processes
(resource containers)
process/thread
scheduling
thread
synchronization
memory
scheduling
paging
swapping
fault
handling
I/O resource
allocation
DMA
services
virtual execution engine
transport
protocols
file systems
synchronization
model
exception
model
IPC
model
file
model
file I/O
model
process/thread
model
file namespace
model
system call interfaces
user visible OS model
asynchronous
events
device drivers
device drivers
volume
management
run-time
loader
configuration
services
kernel
debugger
logging
& tracing
higher level services
authorization
model
boot
strap
fault
management
quality
of service
…
Slide35Instruction Set Architectures (ISAs)The set of instructions supported by a computerWhat bit patterns correspond to what operationsThere are many different ISAs (all incompatible)Different word/bus widths (8, 16, 32, 64 bit)Different features (low power, DSPs, floating point)Different design philosophies (RISC vs. CISC)Competitive reasons (68000, x86, PowerPC)They usually come in familiesNewer models add features (e.g., Pentium vs. 386)But remain upwards-compatible with older modelsA program written for an ISA will run on any compliant CPU
Slide36Privileged vs. General InstructionsMost modern ISAs divide instruction set into privileged vs. generalAny code running on the machine can execute general instructionsProcessor must be put into a special mode to execute privileged instructionsUsually only in that mode when the OS is runningPrivileged instructions do things that are “dangerous”
Slide37PlatformsISA doesn’t completely define a computerFunctionality beyond user mode instructionsInterrupt controllers, DMA controllersMemory management unit, I/O bussesBIOS, configuration, diagnostic featuresMulti-processor & interconnect supportI/O devicesDisplay, disk, network, serial device controllersThese variations are called “platforms”
T
he
platform on which the OS must run
Slide38Portability to Multiple ISAsA successful OS will run on many ISAsSome customers cannot choose their ISAIf you don’t support it, you can’t sell to themMinimal assumptions about specific HWGeneral frameworks are HW independentFile systems, protocols, processes, etc.
HW
assumptions isolated to specific modules
C
ontext
switching, I/O, memory management
C
areful
use of types
W
ord
length, sign extension, byte order, alignment
Slide39Distributing an OSDevelopers want their OS to run on as many machines as possibleThere are many different ISAsAnd other platform differencesEven more types of peripheralsAnd vast numbers of different applications and configurationsHow to get wide, effective distribution?
Slide40Binary Distribution ModelBinary is the opposite of sourceA source distribution must be compiledA binary distribution is ready to runOSes usually distributed in binaryOne binary distribution per ISANo need for special per-OEM OS versionsBinary model for platform supportDevice
drivers can be added, after-market
C
an
be written and distributed by 3
rd
parties
S
ame
driver works with many versions of OS
Slide41Why Not a Source Distribution?What is wrong with distributing an OS in source form?On what are you going to compile it?Are your customers competent to build the OS? Do they want to build the OS?Do you really want to give all of your customers the sources to your main product?Open source OSes are availableBut most users still download the binary versions
Slide42Binary Configuration ModelGood to eliminate manual/static configurationEnable one distribution to serve all usersImprove both ease of use and performanceAutomatic hardware discoverySelf-identifying bussesPCI, USB, PCMCIA, EISA, etc. Automatically find and load required driversAutomatic resource allocation
E
liminate
fixed sized resource pools
D
ynamically
(
re)allocate
resources on demand
Slide43FlexibilityDifferent customers have different needsWe cannot anticipate all possible needsWe must design for flexibility/extensionMechanism/policy separationAllow customers to override default policiesChanging policies without having to change the OSDynamically loadable features
A
llow
new features to be added, after market
F
ile
systems, protocols, load module formats, etc.
F
eature
independence and
orthogonality
Slide44Interface StabilityPeople want new releases of an OSNew features, bug fixes, enhancementsPeople also fear new releases of an OSOS changes can break old applicationsHow can we prevent such problems?Define well specified Application InterfacesApplication programming interfaces (APIs)Application binary interfaces (ABIs)Applications
only use committed interfaces
OS vendors preserve upwards-compatibility
Slide45What’s Special About the OS?It is always in control of the hardwareAutomatically loaded when the machine bootsFirst software to have access to hardwareContinues running while apps come & goIt alone has complete access to hardwarePrivileged instruction set, all of memory & I/OIt mediates applications’ access to hardwareBlock, permit, or modify application requestsIt is trustedTo store and manage critical dataTo always act in good faithIf the OS crashes, it takes everything else with itSo it better not crash . . .
Slide46What Functionality Is In the OS?As much as necessary, as little as possibleOS code is very expensive to develop and maintainFunctionality must be in the OS if it ...Requires the use of privileged instructionsRequires the manipulation of OS data structuresMust maintain security, trust, or resource integrityFunctions should be in libraries if they ...Are a service commonly needed by applicationsDo not actually have to be implemented inside OSBut there is also the performance excuseSome things may be faster if done in the OS
Slide47Where To Offer a Service?Hardware, OS, library or application?Increasing requirements for stability as you move through these optionsHardware services rarely changeOS services can change, but it’s a big dealLibraries are a bit more dynamicApplications can change services much more readily
Slide48Another Reason For This ChoiceWho uses it?Things literally everyone uses belong lower in the hierarchyParticularly if the same service needs to work the same for everyoneThings used by fewer/more specialized parties belong higherParticularly if each party requires a substantially different version of the service
Slide49The OS and SpeedOne reason operating systems get big is based on speedIt’s faster to offer a service in the OS than outside itThus, there’s a push to move services with strong performance requirements down to the OS
Slide50Why Is the OS Faster?Than something at the application level, above it?If it involves processes communicating, working at app level requires scheduling and swapping themThe OS has direct access to many pieces of state and system servicesIf an operation requires such things, application has to pay the cost to enter and leave OS, anywayThe OS can make direct use of privileged instructions
Slide51Is An OS Implementation Always Faster?Not alwaysRunning standard instructions no faster from the OS than from applicationsEntering the OS involves some fairly elaborate state saving and mode changingIf you don’t need special OS services, may be cheaper to manipulate at the app levelMaybe by an order of magnitude
Slide52The OS and AbstractionOne major function of an OS is to offer abstract versions of resourcesAs opposed to actual physical resourcesEssentially, the OS implements the abstract resources using the physical resourcesE.g., processes (an abstraction) are implemented using the CPU and RAM (physical resources)And files (an abstraction) are implemented using disks (a physical resource)
Slide53Why Abstract Resources?The abstractions are typically simpler and better suited for programmers and usersEasier to use than the original resourcesE.g., don’t need to worry about keeping track of disk interruptsCompartmentalize/encapsulate complexityE.g., need not be concerned about what other executing code is doing and how to stay out of its wayEliminate behavior that is irrelevant to userE.g., hide the slow erase cycle of flash memoryCreate more convenient behaviorE.g., make it look like you have the network interface entirely for your own use
Slide54Generalizing AbstractionsLots of variations in machines’ HW and SWSo make many different types appear to be sameSo applications can deal with single common classUsually involves a common unifying modelE.g., portable document format (pdf) for printersOr SCSI standard for disks, CDs and tapesUsually involves a federation frameworkPer sub-type implementations of standard functionsFor example:Printer drivers make different printers look the sameBrowser plug-ins to handle multi-media data
Slide55Why Do We Want This Generality?For example, why do we want all printers to look the same?So we could write applications against a single model, and have it “just work” with all printersWhat’s the alternative?Program our application to know about all possible printers Including those that were invented after we had written our application!
Slide56Does a General Model Limit Us?Does it stick us with the “least common denominator” of a hardware type?Like limiting us to the least-featureful of all printers?Not necessarilyThe model can include “optional features”If present, implemented in a standard wayIf not present, test for them and do “something” if they’re not thereMany devices will have features not in the common modelThere are arguments for and against the value of such features
Slide57Common Types of OS ResourcesSerially reusable resourcesPartitionable resourcesSharable resources
Slide58Serially Reusable ResourcesUsed by multiple clients, but only one at a timeTime multiplexingRequire access control to ensure exclusive useRequire graceful transitions from one user to the nextExamples: printers, bathroom stalls
Slide59What Is A Graceful Transition?A switch that totally hides the fact that the resource used to belong to someone elseDon’t allow the second user to access the resource until the first user is finished with itNo incomplete operations that finish after the transitionEnsure that each subsequent user finds the resource in “like new” conditionNo traces of data or state left over from the first user
Slide60Partitionable ResourcesDivided into disjoint pieces for multiple clientsSpatial multiplexingNeeds access control to ensure: Containment: you cannot access resources outside of your partitionPrivacy: nobody else can access resources in your partitionExamples: RAM, hotel rooms
Slide61Do We Still Need Graceful Transitions?YesMost partitionable resources aren’t permanently allocatedThe page frame of RAM you’re using now will belong to another process laterAs long as it’s “yours,” no transition requiredBut sooner or later it’s likely to become someone else’s
Slide62Shareable ResourcesUsable by multiple concurrent clientsClients do not have to “wait” for access to resourceClients don’t “own” a particular subset of resourceMay involve (effectively) limitless resources Air in a room, shared by occupants Copy of the operating system, shared by processesMay involve under-the-covers multiplexingCell-phone channel (time and frequency multiplexed)Shared network interface (time multiplexed)
Slide63Do We Still Need Graceful Transitions?Typically notThe shareable resource usually doesn’t change stateOr isn’t “reused”We never have to clean up what doesn’t get dirtyLike an execute-only copy of the OSOr things that disappear after useLike the previous second’s bandwidth on a cellular telephone channelShareable resources are great!When you can have them . . .
Slide64A Brief History of Operating Systems1950s … OS? We don’t need no stinking OS!1960s batch processingJob sequencing, memory allocation, I/O services1970s time sharingMulti-user, interactive service, file systems1980s work stations and personal computersGraphical user interfaces, productivity tools1990s work groups and the world wide webS
hared
data, standard protocols, domain services
2000 large scale distributed systems
T
he
network IS the computer
Slide65A Certain IronyToday’s smart phone is immensely more powerful than 1960s mainframesBut we used the mainframes for the biggest computing tasks we hadWhile we use our powerful smart phones to move information around and display stuffWhich has implications for their operating systems . . .
Slide66General OS TrendsThey have grown larger and more sophisticatedTheir role has fundamentally changedFrom shepherding the use of the hardwareTo shielding the applications from the hardwareTo providing powerful application computing platformTo becoming a sophisticated “traffic cop”They still sit between applications and hardwareBest understood through services they provideCapabilities they addApplications they enableProblems they eliminate
Slide67Why?Ultimately because it’s what users wantThe OS must provide core services to applicationsApplications have become more complexMore complex internal behaviorMore complex interfacesMore interactions with other softwareThe OS needs to help with all that complexity
Slide68OS Convergence There are a handful of widely used OSesAnd a few special purpose ones (E.g., real time and embedded system OSes)New ones come along very rarelyOSes in the same family (e.g., Windows or Linux) are used for vastly different purposesMaking things challenging for the OS designerMost OSes are based on pretty old modelsLinux comes from Unix (1970s vintage)Windows from the early 1980s
Slide69Operating Systems for Mobile DevicesWhat’s down at the bottom for our smart phones and other devices?For Apple devices, ultimately XNUBased on Mach (an 80s system), with some features from other 80s systems (like BSD Unix)For Android, ultimately LinuxFor Microsoft, ultimately Windows CEWhich has its origins in the 1990sNone of these is all that new, either
Slide70Why Have OSes Converged?They’re expensive to build and maintainSo it’s a hard business to get into and stay inThey only succeed if users choose them over other OS optionsWhich can’t happen unless you support all the apps the users want (and preferably better)Which requires other parties to do a lot of workYou need to have some clear advantage over present acceptable alternatives
Slide71A Resulting OS ChallengeWe are basing the OS we use today on an architecture designed 20-40 years agoWe can make some changes in the architectureBut not too manyDue to compatibilityAnd fundamental characteristics of the architectureRequires OS designers and builders to shoehorn what’s needed today into what made sense yesterday
Slide72ConclusionUnderstanding operating systems is critical to understanding how computers workOperating systems interact directly with the hardwareOperating systems provide services via abstractionsOperating systems are constrained by many non-technical factors