CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4...

40
CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th , 2013 Prof. John Kubiatowicz http://inst.eecs.berkeley.edu/~cs194-24

Transcript of CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4...

Page 1: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

CS194-24Advanced Operating Systems

Structures and Implementation Lecture 3

OS Structure

February 4th, 2013Prof. John Kubiatowicz

http://inst.eecs.berkeley.edu/~cs194-24

Page 2: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.22/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Goals for Today

• Finish descussion of TDD/BDD• Discuss OS Design

Interactive is important!Ask Questions!

Note: Some slides and/or pictures in the following areadapted from slides ©2013

Page 3: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.32/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Review: Test-Driven Development (TDD)

• Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: – First the developer writes an (initially failing)

automated test case that defines a desired improvement or new function,

– Then produces the minimum amount of code to pass that test, and

– Finally refactors the new code to acceptable standards.• Key thing – Tests come before Code

Write Minimimum amount of

Code to PassWrite Failing

Test

Refactor CodeWhile Still

Passing(DRY out code)

Repeat as necessary

Page 4: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.42/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Review: A Ubiquitous Language for Analysis

• Need a framework for analyzing the process:– As a [X]– I want [Y]– so that [Z]

• Then, need a way of expressing the acceptance criteria in terms of scenarios:– Given some initial context (the givens),– When an event occurs,– Then ensure some outcomes

• Example in cucumber (called, say “valid_card_withdrawal.feature”)

Feature: The Customer tries to withdraw cache using valid ATM cardAs a customer,I want to withdraw cache from an ATMso that I don’t have to wait in line at the bank

scenario: Successful Cache WithdrawalGiven I have an ATM card that is owned by meWhen I request $40and my account has enough moneyThen I will receive $40

scenario: Unsuccessful Cache WithdrawalGiven I have an ATM card that is owned by meWhen I request $40And my account does not have enough moneyThen I will receive an error

Page 5: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.52/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Review: What do Step definitions look like?

• What do these steps translate into?

Given I have an ATM card that is owned by meWhen I request $40and my account has enough moneyThen I will receive $40

• Answer: Regular expressions in a step file:

Given /^I have an ATM card that is owned by me$/ do # Set up machine with card and valid PIN

@my_account ||= Account.newend

When /^I request \$(\d+)$/ do |amount|@my_request = amount

end

And /^my account has enough money$/@my_account.balance.should <= @my_request

end

Then /^I will receive \$(\d+)$/ do |amount|@my_account.request_money(@my_request).should = amount

end

• Steps interact with actual implementation– Reference code you “wish you had”, not “code you already have”

• I put up a pointer to “Rubular” of the Resources page– It lets you enter regular expressions and experiment

Page 6: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.62/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Review: Acceptance Criteria Should Be Executable!

• Cucumber provides an execution environment for Acceptance tests:

development_directory/features:*.feature # Cucumber Filesstep_definitions/*.rb # Step Definitionssupport/*.rb # Supporting code

• How does this all connect? – Files in ‘support’ get loaded early, set up environment before

starting execution and hooks to execute before and after each scenario

– Files in ‘step_definitions’ are global definitions of what to do when a particular step (Given, When, Then, And, But) happens

• Step definitions should be treated like you are designing your own language!– They also connect the high-level language of feature files to the

actual implementation– They may need to tweak the design in interesting ways

• Step definitions typically call code in the implementation before it has been implemented!– Write the code “you wish you had”

Page 7: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.72/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Amusing example: Verify Apple-II

• Start with Apple-II Emulator, then add BDD testing with Cucumber (Thanks to Armando Fox):https://github.com/armandofox/cucumber-virtualii

Feature: enter and run a short BASIC program

As a beginning programmer in the late 1970's So that I can get excited about CS and become a professor someday I want to learn BASIC by entering and running simple programs

Background: The Apple II is booted and the BASIC interpreter is activated Given there is no current BASIC program

Scenario: enter and run Hello World When I enter the following program: | lines | | 10 HOME | | 20 PRINT "HELLO WORLD!" | And I clear the screen And I type "RUN" Then I should see "HELLO WORLD!"

Scenario: enter and run a Fibonacci program When I enter the following program: | lines | | 10 INPUT "COMPUTE FIBONACCI NUMBER "; F

| | 20 N1 = 1 : N2 = 1 | | 30 FOR I = F TO 3 STEP -1 | | 40 T = N2 | | 50 N2 = N2 + N1 | | 60 N1 = T | | 70 NEXT I | | 80 PRINT "RESULT IS "; N2 | And I type "RUN" Then I should see "COMPUTE FIBONACCI NUMBER" When I type "6" Then I should see "RESULT IS 8"

Page 8: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.82/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Verification Methodology• Need for both User Stories (Behaviors) and Component Tests

(Unit testing)– Behavioral Tests represent desired behavior from standpoint of

stakeholders and involve whole code base» Executable documentation!» Slower, whole-system acceptance testing» Run after every change

– Unit testing frameworks (Like Rspec, CUnix, CPPSpec, etc) thoroughly test modules

» Fast execution» Only run tests when change actual module

• Behavioral tests – High-level description independent of implementation– Test files named for behaviors being tested

» When failures happen, know where to start looking– Always in sync with code: tests run after every change– JBehave, Cucumber, etc

• Unit tests – Express individual details of implementation– Consider writing one or more unit test for every module– Can use CPPSpec, Cunit, etc.– Can be systematic, catch corner cases, etc

Page 9: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.92/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

How Agile Methods Address Project Risks

• No longer Delivering Late or Over Budget– Deliver system in tiny, one- or two-week iterations (or mini-

projects)– Always have a working release– Know exactly how much it costs

• No Longer Delivering the Wrong Thing– Can demonstrate new features to stakeholders and make any

tweaks or correct any misunderstandings while work fresh in developer’s minds

• No Longer Unstable in Production– Deliver something on every iteration– Must get good at building and deploying the application

» Releasing to production or testing hardware just another build to just another environment

» Rely on software automation to manage this– Application servers automatically configured, database schemas

automatically updated, code automatically built, assembled, and deployed

– All types of tests automatically executed to ensure system working• No Longer Costly to Maintain

– With first iteration –team is effectively in maintenance mode!– Adding code to a working system, so they have to be very careful

Page 10: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.102/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Administrivia

• Putting up useful resources off the Resources page– Pointers to Ruby, Git– Will put up pointers to C, other languages– Will continue to add resources over time

• What aspects of Project 0 giving people most trouble?– Will be asking for comments on Project 0 at end

of day– How close are people to finishing Project 0?

• Don’t forget to signup for groups today – will be due by midnight tonight!– Remember – groups are 4 to 5 members

Page 11: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.112/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

CPU MMU

VirtualAddresses

PhysicalAddresses

Review: Address Translation

• Address Space– A group of memory addresses usable by

something – Each program (process) and kernel has

potentially different address spaces.• Address Translation:

– Translate from Virtual Addresses (emitted by CPU) into Physical Addresses (of memory)

– Mapping often performed in Hardware by Memory Management Unit (MMU)

Page 12: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.122/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Review: Example of Address Translation

Prog 1Virtual

AddressSpace 1

Prog 2Virtual

AddressSpace 2

CodeDataHeapStack

CodeDataHeapStack

Data 2

Stack 1

Heap 1

OS heap & Stacks

Code 1

Stack 2

Data 1

Heap 2

Code 2

OS code

OS dataTranslation Map 1 Translation Map 2

Physical Address Space

Page 13: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.132/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Recall: Dual Mode Operation

• Hardware provides at least two modes:– “Kernel” mode (or “supervisor” or

“protected”)– “User” mode: Normal programs executed

• Some instructions/ops prohibited in user mode:– Example: cannot modify page tables in user

mode» Attempt to modify Exception generated

• Transitions from user mode to kernel mode:– System Calls, Interrupts, Other exceptions

Page 14: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.142/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Reminder: UNIX System Structure

User Mode

Kernel Mode

Hardware

Applications

Standard Libs

Page 15: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.152/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

OS Resources – at the center of it all!• What do modern OSs do?

– Why all of these pieces running together?

– Is this complexity necessary?• Control of Resources

– Access/No Access/Partial Access

» Check every access to see if it is allowed

– Resource Multiplexing» When multiple valid requests

occur at same time – how to multiplex access?

» What fraction of resource can requester get?

– Performance Isolation» Can requests from one entity

prevent requests from another?• What or Who is a requester???

– Process? User? Public Key?– Think of this as a “Principle”

Access Control and Multiplexing

IndependentRequesters

Page 16: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.162/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

The Protection vs Management Split

• Traditionally Kernels Mix Protection, Performance Isolation, and Management– Protection: Should a principle have access to a given

resource?» Yes or No?» Based on local password file? Thumbprint? Cryptographic Key?

– Bandwidth Isolation» How Much of Bandwidth-Limited resources should the principle

have access to?» Examples:

• 50% CPU• As much Network as Desired• Fraction of Paging Disk for Virtual memory?

– Management: How should the principle use this resource?» Scheduling, Policies» Examples:

• Use my CPU resources to meet realtime deadlines vs highest throughput scheduling

• Keep certain pages in memory• Problem with putting all three of these together is that APIs

limited, complex, or insufficient…

Page 17: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.172/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

What types of Resources Matter?

• Processor, Memory, Cache– Multiplex through: scheduling, Virtual memory– Abstraction: Process, Thread– Need Kernel Level to Multiplex?

» Need to Sandbox somehow» Kernel control of memory, prevent certain instructions

• Network– Multiplex through: Queues, Input Filters– Abstraction: Sockets API– Need Kernel Level to Multiplex?

» Not necessarily – New hardware has on-chip filters» Setup Cost, but not necessarily a per-packet cost» Is network really secure anyway? (Need Crypto!)

• Disk– Multiplex through: Buffer Cache– Abstraction: File System API– Need Kernel Level to Multiplex?

» Traditionally all access control through kernel» What about assigning unlimited access to partitions?

Page 18: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.182/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Operating System Services(Dynamic System Resources)

• Services that (more-or-less) map onto components– Program execution/Job Control– I/O operations

» Standardized interfaces to extremely diverse devices

– File system manipulation» How do you read/write/preserve files?» Looming concern: How do you even find files???

– Communications» Networking protocols/Interface with CyberSpace?

– Security Managers• Cross-cutting capabilities

– Error detection & recovery– Resource allocation– Accounting– Protection

Page 19: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.192/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

System Calls (What is the API)

Page 20: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.202/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Operating Systems Structure(What is the organizational Principle?)

• Simple– Only one or two levels of code

• Layered– Lower levels independent of upper levels

• Microkernel– OS built from many user-level processes

• Modular– Core kernel with Dynamically loadable

modules• ExoKernel• Cell-based OS (Space-Time Partitioning)

Page 21: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.212/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Simple Structure

• MS-DOS – written to provide the most functionality in the least space– Not divided into modules– Interfaces and levels of functionality not well

separated

Page 22: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.222/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

UNIX: Also “Simple” Structure

• UNIX – limited by hardware functionality• Original UNIX operating system consists

of two separable parts:– Systems programs– The kernel

» Consists of everything below the system-call interface and above the physical hardware

» Provides the file system, CPU scheduling, memory management, and other operating-system functions;

» Many interacting functions for one level

Page 23: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.232/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Layered Structure

• Operating system is divided many layers (levels)– Each built on top of lower layers– Bottom layer (layer 0) is hardware– Highest layer (layer N) is the user interface

• Each layer uses functions (operations) and services of only lower-level layers– Advantage: modularity Easier

debugging/Maintenance– Not always possible: Does process scheduler lie

above or below virtual memory layer?» Need to reschedule processor while waiting for

paging» May need to page in information about tasks

• Important: Machine-dependent vs independent layers– Easier migration between platforms– Easier evolution of hardware platform– Good idea for you as well!

Page 24: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.242/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Layered Operating System

Page 25: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.252/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Microkernel Structure

• Moves as much from the kernel into “user” space– Small core OS running at kernel level– OS Services built from many independent user-level processes– Communication between modules with message passing

• Benefits:– Easier to extend a microkernel– Easier to port OS to new architectures– More reliable (less code is running in kernel mode)– Fault Isolation (parts of kernel protected from other parts)– More secure

• Detriments:– Performance overhead severe for naïve implementation

Figure ©WikipediaM

on

olith

icK

ern

el

Mic

rokern

el

Page 26: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.262/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Modules-based Structure

• Most modern operating systems implement modules– Uses object-oriented approach– Each core component is separate– Each talks to the others over known

interfaces– Each is loadable as needed within the kernel

• Overall, similar to layers but with more flexible

Page 27: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.272/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

ExoKernel

• Provide extremely thin layer to present hardware resources directly to users– As little abstraction as possible– Only Protection and Multiplexing of resources

• On top of Exokernel is the LibraryOS which provides much of the traditional functionality of OS in Library

• Low-level abstraction layer

Page 28: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.282/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

A different Take: Focus on Resources

• What might we want to guarantee?– Examples:

» Guarantees of BW (say data committed to Cloud Storage)» Guarantees of Requests/Unit time (DB service)» Guarantees of Latency to Response (Deadline scheduling)» Guarantees of maximum time to Durability in cloud» Guarantees of total energy/battery power available to Cell

• What level of guarantee?– Firm Guarantee (Better than existing systems)

» With high confidence (specified), Maximum deviation, etc.• What does it mean to have guaranteed resources?

– A Service Level Agreement (SLA)?– Something else?

• “Impedance-mismatch” problem– The SLA guarantees properties that programmer/user

wants– The resources required to satisfy SLA are not things that

programmer/user really understands

Page 29: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.292/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Two Level Scheduling:Control vs Data Plane

• Split monolithic scheduling into two pieces:– Course-Grained Resource Allocation and Distribution to Cells

» Chunks of resources (CPUs, Memory Bandwidth, QoS to Services)» Ultimately a hierarchical process negotiated with service providers

– Fine-Grained (User-Level) Application-Specific Scheduling» Applications allowed to utilize their resources in any way they see

fit» Performance Isolation: Other components of the system cannot

interfere with Cells use of resources

MonolithicCPU and Resource

SchedulingApplication Specific

Scheduling

Resource AllocationAnd

Distribution

Two-Level Scheduling

Page 30: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.302/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Space-Time Partitioning

• Spatial Partition: Performance isolation– Each partition

receives a vector of basic resources» A number HW threads» A portion of physical

memory» A portion of shared cache» A fraction of memory

bandwidth

• Partitioning varies over time– Fine-grained multiplexing and

guarantee of resources» Resources are gang-scheduled

• Controlled multiplexing, not uncontrolled virtualization

• Partitioning adapted to the system’s needs

TimeSpace

Sp

ace

Page 31: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.312/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

New OS Primitive: the Cell

• Cell Properties:– A user-level software

component, with guaranteed resources

– Explicit security context which allows access to protected data

– Knowledge of how to adapt itself to new environments (SEJITS)

– Checkpoint/restart to provide fault tolerance, mobility and adaptation

• Execution Environment:– Explicitly parallel computation– Resource Guarantees– Trusted computing base – Secure channels

(intra/interchip) with ability to suspend and restart during migration Lo

catio

n-Adap

tive

Channels

Location-AdaptiveChannels

Processing ResourcesQoS GuaranteesTrusted HW/SW

User-level Mem Mgmt

Address Space A

Address

Space B

Task

User-level

Scheduling

Ad

ap

tatio

nC

heckp

oin

t / R

esta

rt

Page 32: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.322/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Applications Composed ofInterconnected Cells

• Component-based model of computation– Applications consist of interacting components– Components may be local or remote

• Communication defines Security Model– Channels are points at which data may be compromised– Channels define points for QoS constraints– Question: Can we provide proofs of correctness on inter-cell

protocols?• Naming process for initiating endpoints

– Need to find consistent version of library code (within cell)– Need to find compatible remote services– Solution of version constraint problem for running application

SecureChannel

DeviceDrivers

FileService

SecureChannel

Secure

ChannelSecureChannel

SecureChannel

Real-TimeCells

(Audio,Video)

Core ApplicationParallelLibrary

Page 33: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.332/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

UNIX System Structure

User Mode

Kernel Mode

Hardware

Applications

Standard Libs

Page 34: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.342/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Linux Structure

Page 35: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.352/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

History of Unix

Page 36: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.362/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Map of Linux Components (http://www.makelinux.net/kernel_map/)

Page 37: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.372/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Microsoft Windows Structure

Page 38: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.382/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Major Windows Components

• Hardware Abstraction Layer– Hides hardware chipset differences from upper levels of OS

• Kernel Layer– Thread Scheduling– Low-Level Processors Synchronization– Interrupt/Exception Handling– Switching between User/Kernel Mode.

• Executive– Set of services that all environmental subsystems need

» Object Manager» Virtual Memory Manager» Process Manager» Advanced Local Procedure Call Facility» I/O manager» Cache Manager » Security Reference Monitor» Plug-and-Plan and Power Managers» Registry» Booting

• Programmer Interface: Win32 API

Page 39: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.392/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

History of Windows

Page 40: CS194-24 Advanced Operating Systems Structures and Implementation Lecture 3 OS Structure February 4 th, 2013 Prof. John Kubiatowicz cs194-24.

Lec 3.402/4/13 Kubiatowicz CS194-24 ©UCB Fall 2013

Implementation Issues(How is the OS implemented?)

• Policy vs. Mechanism– Policy: What do you want to do?– Mechanism: How are you going to do it?– Should be separated, since both change

• Algorithms used– Linear, Tree-based, Log Structured, etc…

• Event models used– threads vs event loops

• Backward compatability issues– Very important for Windows 2000/XP

• System generation/configuration– How to make generic OS fit on specific

hardware