CS140 – Operating Systems

Instructors: David Mazi`eres, Andrea Bittau (alt)

CAs: Juan Batiz-Benet, Matt Sparks, Kiyoshi Shikuma, Ali Yahya

Stanford University

1/33

Administrivia

•Class web page: http://cs140.scs.stanford.edu/

- All assignments, handouts, lecture notes on-line

•Textbook: Operating System Concepts, 8th Edition,

by Silberschatz, Galvin, and Gagne

- This is the official textbook, but mostly for background

- Class will not rely heavily on textbook

- Old versions okay, or might get away without textbook

•Goal is to make lecture slides the primary reference

- Almost everything I talk about will be on slides

- PDF slides contain links to further reading about topics

- Please download slides from class web page

2/33

Administrivia 2

•Staff mailing list: cs140-staff@scs.stanford.edu

- Please mail staff list rather than individuals for help

•Newsgroup: su.class.cs140 ←main discussion forum

•Key dates:

- Lectures: TTh 4:15-5:30, Gates B03

- Section: Some Fridays, time/location TBD

- Midterm: Tuesday,Feb 8, 4:15–5:30pm

- Final: Wednesday, March 16, 12:15pm–3:15pm

•Exams open book, can bring copies of slides

- No electronic devices permitted

3/33

Lecture videos

•Lectures will be televised for SCPD students

- Can also watch if you miss a lecture, or to review

- But resist temptation to miss a bunch of lectures and watch

them all at once

•SCPD students welcome to attend lecture in person

- 4:15pm lecture time conveniently at end of day

- Many parking spaces don’t require permit after 4pm

•Other notes for SCPD students:

- Please attend exams in person if possible

- Feel free to use newsgroup to find project partners

4/33

Course topics

•Threads & Processes

•Concurrency & Synchronization

•Scheduling

•Virtual Memory

•I/O

•Disks, File systems, Network file systems

•Protection & Security

•Real-life operating systems

•Note: Lectures will often take Unix as an example

- Most current and future OSes heavily influenced by Unix

- Windows is exception; this quarter we will mostly ignore

5/33

Course goals

•Introduce you to operating system concepts

- Hard to use a computer without interacting with OS

- Understanding the OS makes you a more effective programmer

•Cover important systems concepts in general

- Caching, concurrency, memory management, I/O, protection

•Teach you to deal with larger software systems

- Programming assignments much larger than many courses

-Warning: Many people will consider course very hard

- In past, majority of people report ≥15 hours/week

•Prepare you to take graduate OS classes (CS240,

240[a-z])

6/33

Partial preview of the text

Download Goals of Operating System and Administrative - Midterm Exam | CSC 225 and more Exams Computer Architecture and Organization in PDF only on Docsity!

CS140 – Operating Systems

Instructors: David Mazi`eres, Andrea Bittau (alt) CAs: Juan Batiz-Benet, Matt Sparks, Kiyoshi Shikuma, Ali Yahya

Stanford University

Administrivia

• Class web page: http://cs140.scs.stanford.edu/

All assignments, handouts, lecture notes on-line

• Textbook: Operating System Concepts, 8th Edition ,

by Silberschatz, Galvin, and Gagne

This is the official textbook, but mostly for background
Class will not rely heavily on textbook
Old versions okay, or might get away without textbook

• Goal is to make lecture slides the primary reference

Almost everything I talk about will be on slides
PDF slides contain links to further reading about topics
Please download slides from class web page

Administrivia 2

• Staff mailing list: cs140-staff@scs.stanford.edu

Please mail staff list rather than individuals for help

• Newsgroup: su.class.cs140 ← main discussion forum

• Key dates:

Lectures: TTh 4:15-5:30, Gates B
Section: Some Fridays, time/location TBD
Midterm: Tuesday, Feb 8, 4:15–5:30pm
Final: Wednesday, March 16, 12:15pm–3:15pm

• Exams open book, can bring copies of slides

No electronic devices permitted

Lecture videos

• Lectures will be televised for SCPD students

Can also watch if you miss a lecture, or to review
But resist temptation to miss a bunch of lectures and watch them all at once

• SCPD students welcome to attend lecture in person

4:15pm lecture time conveniently at end of day
Many parking spaces don’t require permit after 4pm

• Other notes for SCPD students:

Please attend exams in person if possible
Feel free to use newsgroup to find project partners

Course topics

• Threads & Processes

• Concurrency & Synchronization

• Scheduling

• Virtual Memory

• I/O

• Disks, File systems, Network file systems

• Protection & Security

• Real-life operating systems

• Note: Lectures will often take Unix as an example

Most current and future OSes heavily influenced by Unix
Windows is exception; this quarter we will mostly ignore

Course goals

• Introduce you to operating system concepts

Hard to use a computer without interacting with OS
Understanding the OS makes you a more effective programmer

• Cover important systems concepts in general

Caching, concurrency, memory management, I/O, protection

• Teach you to deal with larger software systems

Programming assignments much larger than many courses
Warning: Many people will consider course very hard
In past, majority of people report ≥15 hours/week

• Prepare you to take graduate OS classes (CS240,

240[a-z])

Programming Assignments

• Implement parts of Pintos operating system

Built for x86 hardware, you will use hardware emulator

• One setup homework (lab 0) due Thursday

• Four implementation projects:

Threads
Multiprogramming
Virtual memory
File system

• Lab 1 distributed at end of this week

Attend section this Friday for project 1 overview

• Implement projects in groups of up to 3 people

Pick your partners today
Lecture will end early so that you can do this 7/

Grading

• No incompletes

Talk to me ASAP if you run into real problems

• 50% of grade based on exams using this quantity:

max (midterm > 0? final : 0, (midterm + final) /2)

• 50% of grade from projects

For each project, 50% of score based on passing test cases
Remaining 50% based on design and style

• Most people’s projects pass most test cases

Please, please, please turn in working code, or no credit here

• Means design and style matter a lot

Large software systems not just about producing working code
Need to produce code other people can understand
That’s why we have group projects 8/

Style

• Must turn in a design document along with code

We supply you with templates for each project’s design doc

• CAs will manually inspect code for correctness

E.g., must actually implement the design
Must handle corner cases (e.g., handle malloc failure)

• Will deduct points for error-prone code w/o errors

Don’t use global variables if automatic ones suffice
Don’t use deceptive names for variables

• Code must be easy to read

Indent code, keep lines and (when possible) functions short
Use a uniform coding style (try to match existing code)
Put comments on structure members, globals, functions
Don’t leave in reams of commented-out garbage code 9/

Assignment requirements

• Do not look at other people’s solutions to projects

• Can read but don’t copy other OSes

E.g., Linux, OpenBSD/FreeBSD, etc.

• Cite any code that inspired your code

As long as you cite what you used, it’s not cheating
Worst case we deduct points if it undermines the assignments

• Projects due on Thursdays at start of lecture

Free extension to midnight if you attend lecture
Or if you are SCPD and watch lecture before midnight

• Ask cs140-staff for extension if you run into trouble

Be sure to tell us: How much have you done? How much is left? When can you finish by? 10/

What is an operating system?

• Layer between applications and hardware

• Makes hardware useful to the programmer

• [Usually] Provides abstractions for applications

Manages and hides details of hardware
Accesses hardware through low/level interfaces unavailable to applications

• [Often] Provides protection

Prevents one process/user from clobbering another

Why study operating systems?

• Operating systems are a maturing field

Most people use a handful of mature OSes
Hard to get people to switch operating systems
Hard to have impact with a new OS

• High-performance servers are an OS issue

Face many of the same issues as OSes

• Resource consumption is an OS issue

Battery life, radio spectrum, etc.

• Security is an OS issue

Hard to achieve security without a solid foundation

• New “smart” devices need new OSes

• Web browsers increasingly face OS issues

Typical OS structure

user kernel

driver

device

P1 P2 P3 P

sockets

TCP/IP

system

file

console disk

device

driver driver

device

network

VM

scheduler

IPC

• Most software runs as user-level processes (P[1-4])

• OS kernel runs in privileged mode [shaded]

Creates/deletes processes
Provides access to hardware 17/

System calls

• Applications can invoke kernel through system calls

Special instruction transfers control to kernel -... which dispatches to one of few hundred syscall handlers

18/

System calls (continued)

• Goal: Do things app. can’t do in unprivileged mode

Like a library call, but into more privileged kernel code

• Kernel supplies well-defined system call interface

Applications set up syscall arguments and trap to kernel
Kernel performs operation and returns result

• Higher-level functions built on syscall interface

printf, scanf, gets, etc. all user-level code

• Example: POSIX/UNIX interface

open, close, read, write, ...

19/

System call example

• Standard library implemented in terms of syscalls

printf – in libc, has same privileges as application
calls write – in kernel, which can send bits out serial port 20/

UNIX file system calls

• Applications “open” files (or devices) by name

I/O happens through open files

• int open(char path, int flags, /mode*/...);

flags: O RDONLY, O WRONLY, O RDWR
O CREAT: create the file if non-existent
O EXCL: (w. O CREAT) create if file exists already
O TRUNC: Truncate the file
O APPEND: Start writing from end of file
mode: final argument with O CREAT

• Returns file descriptor—used for all I/O to file

Error returns

• What if open fails? Returns -1 (invalid fd)

• Most system calls return -1 on failure

Specific kind of error in global int errno

• #include <sys/errno.h> for possible values

2 = ENOENT “No such file or directory”
13 = EACCES “Permission Denied”

• perror function prints human-readable message

perror ("initfile");

→ “initfile: No such file or directory”

Operations on file descriptors

• int read (int fd, void *buf, int nbytes);

Returns number of bytes read
Returns 0 bytes at end of file, or -1 on error

• int write (int fd, void *buf, int nbytes);

Returns number of bytes written, -1 on error

• off t lseek (int fd, off t pos, int whence);

whence: 0 – start, 1 – current, 2 – end

⊲ Returns previous file offset, or -1 on error

• int close (int fd);

23/

File descriptor numbers

• File descriptors are inherited by processes

When one process spawns another, same fds by default

• Descriptors 0, 1, and 2 have special meaning

0 – “standard input” (stdin in ANSI C)
1 – “standard output” (stdout, printf in ANSI C)
2 – “standard error” (stderr, perror in ANSI C)
Normally all three attached to terminal

• Example: type.c

Prints the contents of a file to stdout

24/

type.c

void typefile (char *filename) { int fd, nread; char buf[1024]; fd = open (filename, O_RDONLY); if (fd == -1) { perror (filename); return; } while ((nread = read (fd, buf, sizeof (buf))) > 0) write (1, buf, nread); close (fd); }

25/

Different system contexts

• A system can typically be in one of several contexts

• User-level – running an application

• Kernel process context

Running kernel code on behalf of a particular process
E.g., performing system call
Also exception (mem. fault, numeric exception, etc.)
Or executing a kernel-only process (e.g., network file server)

• Kernel code not associated w. a process

Timer interrupt (hardclock)
Device interrupt
“Softirqs”, “Tasklets” (Linux-specific terms)

• Context switch code – changing address spaces

26/

Transitions between contexts

• User → kernel process context: syscall, page fault

• User/process context → interrupt handler: hardware

• Process context → user/context switch: return

• Process context → context switch: sleep

• Context switch → user/process context

CPU preemption

• Protection mechanism to prevent monopolizing CPU

• E.g., kernel programs timer to interrupt every 10 ms

Must be in supervisor mode to write appropriate I/O registers
User code cannot re-program interval timer

• Kernel sets interrupt to vector back to kernel

Regains control whenever interval timer fires
Gives CPU to another process if someone else needs it
Note: must be in supervisor mode to set interrupt entry points
No way for user code to hijack interrupt handler

• Result: Cannot monopolize CPU with infinite loop

At worst get 1/ N of CPU with N CPU-hungry processes

type.c Tue Jan 04 15:48:15 2011 1

#include <stdio.h> #include <unistd.h> #include <fcntl.h>

void typefile (char *filename) { int fd, nread; char buf[1024];

fd = open (filename, O_RDONLY); if (fd == -1) { perror (filename); return; }

while ((nread = read (fd, buf, sizeof (buf))) > 0) write (1, buf, nread);

close (fd); }

int main (int argc, char **argv) { int argno; for (argno = 1; argno < argc; argno++) typefile (argv[argno]); exit (0); }

Goals of Operating System and Administrative - Midterm Exam | CSC 225, Exams of Computer Architecture and Organization

Related documents

Partial preview of the text

Download Goals of Operating System and Administrative - Midterm Exam | CSC 225 and more Exams Computer Architecture and Organization in PDF only on Docsity!

CS140 – Operating Systems

Administrivia

• Class web page: http://cs140.scs.stanford.edu/

• Textbook: Operating System Concepts, 8th Edition ,

by Silberschatz, Galvin, and Gagne

• Goal is to make lecture slides the primary reference

Administrivia 2

• Staff mailing list: cs140-staff@scs.stanford.edu

• Newsgroup: su.class.cs140 ← main discussion forum

• Key dates:

• Exams open book, can bring copies of slides

Lecture videos

• Lectures will be televised for SCPD students

• SCPD students welcome to attend lecture in person

• Other notes for SCPD students:

Course topics

• Threads & Processes

• Concurrency & Synchronization

• Scheduling

• Virtual Memory

• I/O

• Disks, File systems, Network file systems

• Protection & Security

• Real-life operating systems

• Note: Lectures will often take Unix as an example

Course goals

• Introduce you to operating system concepts

• Cover important systems concepts in general

• Teach you to deal with larger software systems

• Prepare you to take graduate OS classes (CS240,

240[a-z])

Programming Assignments

• Implement parts of Pintos operating system

• One setup homework (lab 0) due Thursday

• Four implementation projects:

• Lab 1 distributed at end of this week

• Implement projects in groups of up to 3 people

Grading

• No incompletes

• 50% of grade based on exams using this quantity:

max (midterm > 0? final : 0, (midterm + final) /2)

• 50% of grade from projects

• Most people’s projects pass most test cases

• Means design and style matter a lot

Style

• Must turn in a design document along with code

• CAs will manually inspect code for correctness

• Will deduct points for error-prone code w/o errors

• Code must be easy to read

Assignment requirements

• Do not look at other people’s solutions to projects

• Can read but don’t copy other OSes

• Cite any code that inspired your code

• Projects due on Thursdays at start of lecture

• Ask cs140-staff for extension if you run into trouble

What is an operating system?

• Layer between applications and hardware

• Makes hardware useful to the programmer

• [Usually] Provides abstractions for applications

• [Often] Provides protection

Why study operating systems?

• Operating systems are a maturing field

• High-performance servers are an OS issue

• Resource consumption is an OS issue

• Security is an OS issue

• New “smart” devices need new OSes

• Web browsers increasingly face OS issues

Typical OS structure

driver

device

P1 P2 P3 P

sockets

TCP/IP

system

file

console disk