Hardware/Software Interface OS Structure

1 . Goals for Today CS194-24 • Finish discussion of TDD/BDD Advanced Operating Systems • Operating Systems Resources Structures and Implementation • API access to hardware resources Lecture 3 • OS Design Hardware/Software Interface Interactive is important! OS Structure Ask Questions! January 29th, 2014 Prof. John Kubiatowicz http://inst.eecs.berkeley.edu/~cs194-24 Note: Some slides and/or pictures in the following are adapted from slides ©2013 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.2 Review: Test-Driven Development (TDD) Review: A Ubiquitous Language for Analysis • Need a framework for analyzing the process: Write Minimimum – As a [X] amount of – I want [Y] Code to Pass – so that [Z] Write Refactor Code • Then, need a way of expressing the acceptance criteria in terms of scenarios: Failing While Still Passing (DRY out code) – Given some initial context (the givens), Test Repeat as necessary – When an event occurs, – Then ensure some outcomes • Test-driven development (TDD) is a software development • Example in cucumber (called, say “valid_card_withdrawal.feature”) process that relies on the repetition of a very short Feature: The Customer tries to withdraw cache using valid ATM card development cycle: As a customer, I want to withdraw cache from an ATM – First the developer writes an (initially failing) automated test so that I don’t have to wait in line at the bank scenario: Successful Cache Withdrawal case that defines a desired improvement or new function, Given I have an ATM card that is owned by me When I request $40 – Then produces the minimum amount of code to pass that and my account has enough money Then I will receive $40 test, and scenario: Unsuccessful Cache Withdrawal Given I have an ATM card that is owned by me – Finally refactors the new code to acceptable standards. When I request $40 And my account does not have enough money • Key thing – Tests come before Code Then I will receive an error 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.3 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.4 

2 . Review: What do Step definitions look like? Review: Amusing example: Verify Apple-II • What do these steps translate into? • Start with Apple-II Emulator, then add BDD Given I have an ATM card that is owned by me testing with Cucumber (Thanks to Armando Fox): When I request $40 and my account has enough money https://github.com/armandofox/cucumber-virtualii Then I will receive $40 Feature: enter and run a short BASIC program • Answer: Regular expressions in a step file: Given /^I have an ATM card that is owned by me$/ do As a beginning programmer in the late 1970's # Set up machine with card and valid PIN So that I can get excited about CS and @my_account ||= Account.new become a professor someday end Scenario: enter and run a Fibonacci program I want to learn BASIC by entering and running When /^I request \$(\d+)$/ do |amount| simple programs When I enter the following program: @my_request = amount | lines | end | 10 INPUT "COMPUTE FIBONACCI NUMBER "; F | Background: The Apple II is booted and the And /^my account has enough money$/ BASIC interpreter is activated | 20 N1 = 1 : N2 = 1 | @my_account.balance.should <= @my_request Given there is no current BASIC program | 30 FOR I = F TO 3 STEP -1 | end | 40 T = N2 | Then /^I will receive \$(\d+)$/ do |amount| Scenario: enter and run Hello World | 50 N2 = N2 + N1 | @my_account.request_money(@my_request).should = amount end When I enter the following program: | 60 N1 = T | | lines | | 70 NEXT I | • Steps interact with actual implementation | 10 HOME | | 80 PRINT "RESULT IS "; N2 | – Reference code you “wish you had”, not “code you already have” | 20 PRINT "HELLO WORLD!" | And I type "RUN" • I put up a pointer to “Rubular” of the Resources page And I clear the screen Then I should see "COMPUTE FIBONACCI NUMBER" And I type "RUN" When I type "6" – It lets you enter regular expressions and experiment Then I should see "HELLO WORLD!" Then I should see "RESULT IS 8" 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.5 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.6 Verification Methodology How Agile Methods Address Project Risks • Need for both User Stories (Behaviors) and Component Tests • No longer Delivering Late or Over Budget (Unit testing) – Deliver system in tiny, one- or two-week iterations (or mini- – Behavioral Tests represent desired behavior from standpoint of projects) stakeholders and involve whole code base » Executable documentation! – Always have a working release » Slower, whole-system acceptance testing – Know exactly how much it costs » Run after every change • No Longer Delivering the Wrong Thing – Unit testing frameworks (Like Rspec, CUnit, CPPSpec, etc) – Can demonstrate new features to stakeholders and make any thoroughly test modules tweaks or correct any misunderstandings while work fresh in » Fast execution developer’s minds » Only run tests when change actual module • No Longer Unstable in Production • Behavioral tests – Deliver something on every iteration – High-level description independent of implementation – Must get good at building and deploying the application – Test files named for behaviors being tested » Releasing to production or testing hardware just another build to just another environment » When failures happen, know where to start looking » Rely on software automation to manage this – Always in sync with code: tests run after every change – Application servers automatically configured, database schemas – JBehave, Cucumber, etc automatically updated, code automatically built, assembled, and • Unit tests deployed – Express individual details of implementation – All types of tests automatically executed to ensure system working – Consider writing one or more unit test for every module • No Longer Costly to Maintain – Can use CPPSpec, Cunit, etc. – With first iteration –team is effectively in maintenance mode! – Can be systematic, catch corner cases, etc – Adding code to a working system, so they have to be very careful 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.7 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.8 

3 . Recall: UNIX System Structure OS Resources – at the center of it all! • What do modern OSs do? – Control access to resources! Independent • Control of Resources Requesters Applications – Access/No Access/ User Mode Partial Access Standard Libs » Check every access to see if it is allowed – Resource Multiplexing » When multiple valid requests Access Control and Multiplexing Kernel Mode occur at same time – how to multiplex access? » What fraction of resource can requester get? – Performance Isolation » Can requests from one entity Hardware prevent requests from another? • What or Who is a requester??? – Process? User? Public Key? – Think of this as a “Principle” 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.9 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.10 What is a Resource? More Complex Resources: Operating System Services • Processor, Memory, Cache • System Services are really complex resources – Multiplex through: scheduling, Virtual memory – File system (Uses Disk Drive) – Abstraction: Process, Thread » File API: Create, Read, Write, Delete – Need Kernel Level to Multiplex? » Access Control: User, Group, World, Read/Write/Execute » Need to Sandbox somehow – Windows System (Uses Graphics Card) » Kernel control of memory, prevent certain instructions » Windowing API: Write Text, Draw/Fill in figures • Network » Access Control: Per Window (User created) – Multiplex through: Queues, Input Filters – Data Base (Uses Disk Drive or Memory or Network) – Abstraction: Sockets API » DB API: SQL Queries and Transactions – Need Kernel Level to Multiplex? » Access Control: Per user, Group, others » Not necessarily – New hardware has on-chip filters – Lock Service (Memory) » Setup Cost, but not necessarily a per-packet cost » Lock API: Acquire (Read, Write), Release » Is network really secure anyway? (Need Crypto!) » Access Control: By group/per user • Disk • Access controlled through syscall interface (Kernel Level) – Multiplex through: Buffer Cache – Funnel all access through trusted (verified) API – Abstraction: File System API » Kernel controls access to API, verifies identity – Need Kernel Level to Multiplex? » Service controls access to resources using identity » Traditionally all access control through kernel – Service decides multiplexing/isolation policies » What about assigning unlimited access to partitions? » Often based on first-come-first-serve! 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.11 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.12 

4 . The Protection vs Management Split Administrivia • Kernels Mix Protection, Performance Isolation, and Management • Putting up useful resources off the Resources page – Protection: Should a principle have access to a given resource? – Pointers to Ruby, Git » Yes or No? – Will put up pointers to C, other languages » Based on local password file? Thumbprint? Cryptographic Key? – Performance Isolation – Will continue to add resources over time » How Much of Bandwidth-Limited resources should the principle • Issues with Redmine site: Sorry about that have access to? » Examples: – Seems like a plugin I used has some issues • 50% CPU » Put in temporary fix • As much Network as Desired » Key management issues should now fix themselves every 15 • Fraction of Paging Disk for Virtual memory? minutes (at max) if they occur – Management: How should the principle use this resource? – Also, possible that will get a 500 error first time you » Scheduling, Policies try to look at Repository link » Examples: » This is because of the size of the repository! • Use my CPU resources to meet realtime deadlines vs highest • Group Signup will be due by Monday throughput scheduling • Keep certain pages in memory – Remember – groups are 4 to 5 members • Problem with putting all three of these together is that APIs – Signup link will be operational soon (don’t try until limited, complex, or insufficient… Friday) 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.13 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.14 Traditional Approach to Handling Resource Alternative: Mechanisms (or even Policy!?) in HW • Example: Send message from one processor to another Source Dest User-Level Code – Check Permissions, Format Message Program Program (With Libraries) – Enforce forward progress, Handle interrupts – Prevent Denial Of Service (DOS) and/or Deadlock • Traditional Approach: Use a system call+OS Service Hardware Hardware Specs Specs QoS QoS Interface Network Interface Hardware Source Dest User-Level Code (User-level) (User-level) Program Program (With Libraries) OS Policy SysCall SysCall • Permit user-level code to send messages Message Kernel (OS) Message – Have hardware check permission and/or rate OS Service Service Code Service – Have hardware enforce format/consistency Device Device – Have hardware guarantee forward progress Driver Driver – Have Hardware deliver messages/interrupts to usercode Hardware Network Hardware Hardware • OS sets registers to control behavior based on policy Interface Interface 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.15 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.16 

5 . Push Access Control to Hardware: User-Level Alewife Messaging Sharing of Network Interface • Send message • What if user in middle of constructing message and – write words to special network must context switch??? interface registers – Need Atomic Send operation! – Execute atomic launch instruction » Message either completely in network or not at all • Receive » Can save/restore user’s work if necessary (think about single set of network interface registers – Generate interrupt/launch user-level thread context – J-Machine mistake: after start sending message must let sender finish – Examine message by reading from » Flits start entering network with first SEND instruction special network interface registers » Only a SENDE instruction constructs tail of message – Execute dispose message • Receive Atomicity – Exit atomic section – If want to allow user-level interrupts or polling, must give user control over network reception » Closer user is to network, easier it is for him/her to screw it up: Refuse to empty network, etc » However, must allow atomicity: way for good user to select when their message handlers get interrupted – Polling: ultimate receive atomicity – never interrupted » Fine as long as user keeps absorbing messages 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.17 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.18 Alewife User-level event mechanism System Calls: Details • Disable during polling: • Challenge: Interaction Despite Isolation – How to isolate processes and their resources… – Allowed as long as user » While still permitting them to request help from the kernel code properly removing » Letting them interact with resources while maintaining usage policies such as security, QoS, etc messages – Letting processes interact with one another in a controlled way » Through messages, shared memory, etc • Disable as atomicity for • Enter the System Call interface user-level interrupt – Layer between the hardware and user-space processes – Allowed as long as user – Programming interface to the services provided by the OS removes message quickly • Mostly accessed by programs via a high-level Application Program Interface (API) rather than directly • Emulation of hardware – Get at system calls by linking with libraries in glibc delivery in software: Call to Printf() in the Write() printf() C library system call • Three most common APIs are: – Win32 API for Windows – POSIX API for POSIX-based systems (including virtually all versions of UNIX, Linux, and Mac OS X) – Java API for the Java virtual machine (JVM) 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.19 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.20 

6 . Example of System Call usage Example: Use strace to trace syscalls • System call sequence to copy the contents of one • prompt% strace wc production.log file to another file: execve("/usr/bin/wc", ["wc", "production.log"], [/* 52 vars */]) = 0 brk(0) = 0x1987000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff24b8f7000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=137151, ...}) = 0 mmap(NULL, 137151, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff24b8d5000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\355\241,0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1922112, ...}) = 0 mmap(0x302ca00000, 3745960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x302ca00000 mprotect(0x302cb89000, 2097152, PROT_NONE) = 0 mmap(0x302cd89000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x189000) = 0x302cd89000 mmap(0x302cd8e000, 18600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x302cd8e000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff24b8d4000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff24b8d3000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff24b8d2000 arch_prctl(ARCH_SET_FS, 0x7ff24b8d3700) = 0 mprotect(0x302cd89000, 16384, PROT_READ) = 0 mprotect(0x302c81f000, 4096, PROT_READ) = 0 munmap(0x7ff24b8d5000, 137151) = 0 brk(0) = 0x1987000 brk(0x19a8000) = 0x19a8000 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=99158576, ...}) = 0 mmap(NULL, 99158576, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff245a41000 close(3) = 0 stat("production.log", {st_mode=S_IFREG|0644, st_size=526550, ...}) = 0 open("production.log", O_RDONLY) = 3 read(3, "# Logfile created on Fri Dec 28 "..., 16384) = 16384 open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=26060, ...}) = 0 mmap(NULL, 26060, PROT_READ, MAP_SHARED, 4, 0) = 0x7ff24b8f0000 close(4) = 0 read(3, "m: cannot remove `/tmp/fixrepo/g"..., 16384) = 16384 read(3, "a36de93203e0b4972c1a3c81904e': P"..., 16384) = 16384 read(3, "xrepo/git-tess/gitolite-admin/.g"..., 16384) = 16384 Many repetitions of these reads read(3, "ixrepo/git-tess/gitolite-admin\n "..., 16384) = 16384 read(3, "ite/redmine/vendor/plugins/redmi"..., 16384) = 16384 read(3, "ited with positive recursionChec"..., 16384) = 16384 read(3, "ting changes to gitolite-admin r"..., 16384) = 2262 read(3, "", 16384) = 0 • Many crossings of the User/Kernel boundary! fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff24b8ef000 write(1, " 4704 28993 526550 production."..., 36 4704 28993 526550 production.log) = 36 close(3) = 0 – The cost of traversing this boundary can be high close(1) = 0 munmap(0x7ff24b8ef000, 4096) = 0 close(2) = 0 exit_group(0) 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.21 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.22 Example of Standard API System Call Implementation • Typically, a number associated with each system call – System-call interface maintains a table indexed according to these numbers – The fact that the call is by “number”, is essential for security reasons! • The system call interface invokes intended system call in OS kernel and returns status of the system call and any return values – Return value: often a long (integer) » Return of zero is usually a sign of success, but not always » Return of -1 is almost always reflects an error – On error – return code placed into global “errno” variable » Can translate into human-readable errors with the “perror()” call • The caller need know nothing about how the system call is implemented – Just needs to obey API and understand what OS will do as a result call – Most details of OS interface hidden from programmer by API » Managed by run-time support library (set of functions built into libraries included with compiler) 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.23 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.24 

7 . API – System Call – OS Relationship System Call Parameter Passing • Often, more information is required than simply identity of desired system call – Exact type and amount of information vary according to OS and call • Three general methods used to pass parameters to the OS – Simplest: pass the parameters in registers » In some cases, may be more parameters than registers – Parameters stored in a block, or table, in memory, and address of block passed as a parameter in a register » This approach taken by Linux and Solaris – Parameters placed, or pushed, onto the stack by the program and popped off the stack by the operating system – Block and stack methods do not limit the number or length of parameters being passed 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.25 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.26 Parameter Passing via Table Types of System Calls • Process control – end, abort – load, execute – create process, terminate process – get process attributes, set process attributes – wait for time – wait event, signal event – allocate and free memory • Kernel must always verify parameters passed to – Dump memory if error it by the user – Debugger for determining bugs, single step execution – Are parameters in a reasonable range? – Locks for managing access to shared data between – Are memory addresses actually owned by the processes calling user (rather than bogus addresses) 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.27 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.28 

8 . Types of System Calls (Con’t) Types of System Calls (Cont.) • File management • Communications – create file, delete file – create, delete communication connection – open, close file – send, receive messages if message passing model to – read, write, reposition host name or process name – get and set file attributes » From client to server • Device management – request device, release device – Shared-memory model create and gain access to memory regions – read, write, reposition – get device attributes, set device attributes – transfer status information – logically attach or detach devices – attach and detach remote devices • Information maintenance • Protection – get time or date, set time or date – Control access to resources – get system data, set system data – Get and set permissions – get and set process, file, or device attributes – Allow and deny user access 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.29 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.30 POSIX standard POSIX (cont) • Process Primitives: • Portable Operating System Interface for UNIX – fork, execl, execlp, execv, execve, execvp, wit, waitpid » An attempt to standardize a “UNIXy” interface – _exit, kill, sigxxx, alarm, pause, sleep…. • Conformance: IEEE POSIX 1003.1 and ISO/IEC 9945 • Example file access primitives: – Latest version from 2008 – opendir, readdir, rewinddir, closedir, chdir, getcwd, open, creat, umask, – Originally one document consisting of a core programming inteface – link, mkdir, unlink, rmdir, rename, stat, fstat, access, fchmod, chown, now 19 separate docs utime, ftruncate,pathconf,fpathconf – Many OSes provide “partial conformance” (including Linux) • I/O primitives: – pipe, dup, dup2, close, read, write, fcntl, lseek, fsync • What does POSIX define? • C-Language primitives: – POSIX.1: Core Services – abort, exit, fclose, fdopen, fflush, fgetc, fgets, fileno, fopen, fprintf, » Process Creation and Control fputc, fputs, fread, freopen, fscanf, fseek, ftell, fwrite, getc, getchar, » Signals gets, perror, printf, putc, putchar, puts, remove, rewind, scanf, » Floating Point Exceptions, Segmentation/memory violations, illegal setlocale, siglongjmp, sigsetjmp, tmpfile, tmpnam, tzset instructions, Bus Erors • Synchronization: » Timers – sem_init, sem_destroy, sem_wait, sem_trywait, sem_post, » File and Directory Operations pthread_mutex_init, pthread_mutex_destroy, pthread_mutex_lock, pthread_mutex_trylock, pthread_mutex_unlock » Pipes • Memory Management » C Library (Standard C) – mmap, mprotect, msync, munmap » I/O Port Interface and Control » Process Triggers • How to get information on a system call? – Type “man callname”, i.e. “man open” – POSIX.1b: Realtime Extensions – System calls are in section “2” of the man pages – POSIX.2: Shell and Utilities 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.31 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.32 

9 . Examples of Windows and Portability Unix System Calls • POSIX does provide some portability – But is still pretty high level – Does not specify file systems, network interfaces, power management, other important things – Many variations in compilers, user programs, libraries, other build environment aspects • UNIX Portability: – C-preprocessor conditional compilation – Conditional and multi-target Makefile Rules – GNU configure scripts to generate Makefiles – Shell environment variables (LD_LIBRARY_PATH, LD_PRELOAD, others) 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.33 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.34 Operating Systems Structure Standard C Library Example (What is the organizational Principle?) • C program invoking printf() library call, which • Simple calls write() system call – 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) 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.35 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.36 

10 . Implementation Issues (How is the OS implemented?) Conclusion • Test-Driven Development (TDD) • Policy vs. Mechanism – Write tests first, then write code, then refactor – Policy: What do you want to do? • Behavior-Driven Development (BDD) – Mechanism: How are you going to do it? – Executable Behavior specifications – Cucumber for Integration Behaviors, Unit tests for – Should be separated, since both change implementation. • Resource Control: In HW or SW! • Algorithms used – Access/No Access/Partial Access – Linear, Tree-based, Log Structured, etc… – Resource Multiplexing • Event models used – Performance Isolation • System-Call interface – threads vs event loops – This is the I/O for the process “virtual machine” – Accomplished with special trap instructions which vector off a • Backward compatability issues table of system calls – Very important for Windows 2000/XP – Usually programmers use the standard API provided by the C library rather than direct system-call interface • System generation/configuration • POSIX interface – An attempt to standardize “unixy” Oses – How to make generic OS fit on specific hardware • OS Structure: Many approaches – But it is all about control of Resource! 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.37 1/29/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 3.38