/
Introduction CS   111 Operating Introduction CS   111 Operating

Introduction CS 111 Operating - PowerPoint Presentation

startse
startse . @startse
Follow
342 views
Uploaded On 2020-08-28

Introduction CS 111 Operating - PPT Presentation

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: 809047

system operating resources systems operating system systems resources software hardware write set features access binary distribution data resource user

Share:

Link:

Embed:

Download Presentation from below link

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.


Presentation Transcript

Slide1

IntroductionCS 111Operating System Principles Peter Reiher

Slide2

OutlineAdministrative materialsIntroduction to the courseWhy study operating systems?Basics of operating systems

Slide3

Administrative IssuesInstructor and TAsLoad and prerequisitesWeb site, syllabus, reading, and lecturesExams, homework, projectsGradingAcademic honesty

Slide4

Instructor: 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

Slide5

My OS BackgroundMy Ph.D. dissertation was on the Locus operating systemMuch research on file systemsFicus, Rumor, Truffles, ConquestResearch on OS security issuesData Tethers

Slide6

TADiyu Zhouzhoudiyu@cs.ucla.eduLab sessions:Lab 1A, Fridays 10-12 AM, Geology 4660Office hours to be announced

Slide7

Instructor/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

Slide8

Web SiteSome materials found on CCLE web siteProject materials, for exampleMost materials here:http://www.lasr.cs.ucla.edu/classes/111_summer17What’s there:Schedules for reading, lectures, exams, projectsCopies of lecture slides (Powerpoint and PDF)AnnouncementsSample midterm and final problems

Slide9

Prerequisite 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

Slide10

Course FormatTwo weekly reading assignmentsMostly from the primary textSome supplementary materials available on webTwo weekly lecturesFour (10-25 hour) individual projectsExploring and exploiting OS featuresPlus one warm-up projectA midterm and a final exam

Slide11

Course 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

Slide12

Primary Text for CourseRemzi and Andrea Arpaci-Dusseau: Operating Systems: Three Easy PiecesFreely available on line at http://pages.cs.wisc.edu/~remzi/OSTEP/Supplemented with web-based materials

Slide13

Course GradingBasis for grading:Class evaluation 1%1 midterm exam 24%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

Slide14

Midterm ExaminationWhen: First lecture of the 6th week (in class section, Tuesday, July 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

Slide15

Final ExamWhen: Thursday, August 24, in classScope: Entire courseFormat:4-6 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

Slide16

Lab 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

Slide17

Late Assignments & Make-upsLabsDue dates set by TATA also sets policy on late assignmentsThe TA will handle all issues related to labsAsk him, not meDon’t expect me to overrule his decisionsExamsAlternate times or make-ups only possible with prior consent of the instructorIf you miss a test, too bad

Slide18

Academic 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

Slide19

Academic 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 useException: one project allows two person teams

Protect

yourself

Do

not show other people your solutions

Be

careful with old listings

Slide20

Academic 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

Slide21

Introduction to the CoursePurpose of course and relationships to other coursesWhy study operating systems?What is an operating system?

Slide22

What Will CS 111 Do?Build on concepts from other coursesData structures, programming languages, assembly language programming, computer architectures, ...Prepare you for advanced coursesData bases, data mining, and distributed computingSecurity, fault-tolerance, high availabilityNetwork protocols, computer system modelingProvide you with foundation conceptsProcesses, threads, virtual address space, filesCapabilities, synchronization, leases, deadlock

Slide23

Why Study Operating Systems?Why do we have them, in the first place?Why are they important?What do they do for us?

Slide24

Starting From the Bottom

Here’s what you’ve got

Here’s what you want

Slide25

What Can You Do With What You’ve Got? MOV ADD JMP

SQRTPD

Read or write some binary words

READ

REQUEST SENSE

Read or write a block of data

Report X and Y movements

Write to groups of pixels

Slide26

And You Want This?

Slide27

You’re Going to Need Some HelpAnd that’s what the operating system is aboutHelping you perform complex operationsUsing various hardwareAnd probably various bits of softwareWhile hiding the complexityAnd making sure nothing gets in the way of anything else

Slide28

What Is An Operating System, Anyway?System software intended to provide support for higher level applicationsSome higher level system softwareBut primarily for user processesThe software that sits between the hardware and everything elseThe software that hides nasty detailsOf hardware, software, and common tasksOn a good day, the OS is your best computing friend

Slide29

But Why Are You Studying Them?High probability none of you will ever write an operating systemOr even fix an operating system bugNot very many different operating systems are in useSo the number of developers for them is smallSo why should you care about them?

Slide30

Everybody Has OnePractically all computing devices you will ever use has an operating systemServers, laptops, desktop machines, tablets, smart phones, game consoles, set-top boxesMany things you don’t think of as computers have CPUs in sideUsually with an operating systemInternet of Things devicesSo you will work with operating systems

Slide31

How Do You Work With OSes?You configure themYou use their features when you write programsYou rely on services that they offerMemory managementPersistent storageScheduling and synchronizationInterprocess communicationsSecurity

Slide32

Another Good ReasonMany hard problems have been tackled in the context of operating systemsHow to coordinate separate computationsHow to manage shared resourcesHow to virtualize hardware and softwareHow to organize communicationsHow to protect your computing resourcesThe operating system solutions are often applicable to programs and systems you write

Slide33

The Philosophy of Operating SystemsOver the years we’ve developed some wisdom in building operating systemsLessons learned, things that worked well, things that worked poorlyThis wisdom informs modern operating system designAnd much of it carries over into development of any complex software system

Slide34

Some OS WisdomView services as objects and operationsBehind every object there is a data structureInterface vs. implementationAn implementation is not a specificationMany compliant implementations are possibleInappropriate dependencies cause problemsAn interface specification is a contractSpecifies responsibilities of producers & consumersBasis for product/release interoperability

Slide35

More OS WisdomModularity and functional encapsulationComplexity hiding and appropriate abstractionSeparate 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 oddsCorrectness doesn’t always win . . .

Slide36

What 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

Slide37

What 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

Slide38

What 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

Slide39

Where 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,

...)

Slide40

What’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 . . .

Slide41

Instruction 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

Slide42

Privileged 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”

Slide43

PlatformsISA 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

Slide44

Portability 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 themWhich implies we’ll abstract the ISAMinimal 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

Slide45

Distributing 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?

Slide46

Binary 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

Slide47

Why 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

Slide48

Binary 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

Slide49

FlexibilityDifferent 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

Slide50

Interface 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

Slide51

What 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

Slide52

The 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)

Slide53

Why 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

Slide54

Generalizing 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

Slide55

Why 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!

Slide56

Does 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

Slide57

Common Types of OS ResourcesSerially reusable resourcesPartitionable resourcesSharable resources

Slide58

Serially 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

Slide59

What 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

Slide60

Partitionable 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

Slide61

Do 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

Slide62

Shareable 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)

Slide63

Do 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 . . .

Slide64

General 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

Slide65

Why?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

Slide66

OS 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

Slide67

Why 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

Slide68

ConclusionUnderstanding 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