Basic OS Progamming Abstrac2ons

Similar documents
Basic OS Progamming Abstrac7ons

Basic OS Programming Abstractions (and Lab 1 Overview)

Signals and Inter-Process Communica.on

CSE 506: Opera.ng Systems Signals and Inter-Process Communica.on

Ricardo Rocha. Department of Computer Science Faculty of Sciences University of Porto

Process Creation in UNIX

Outline. OS Interface to Devices. System Input/Output. CSCI 4061 Introduction to Operating Systems. System I/O and Files. Instructor: Abhishek Chandra

Processes often need to communicate. CSCB09: Software Tools and Systems Programming. Solution: Pipes. Recall: I/O mechanisms in C

Virtual File System. Don Porter CSE 306

Process Management! Goals of this Lecture!

File Descriptors and Piping

Pipes and FIFOs. Woo-Yeong Jeong Computer Systems Laboratory Sungkyunkwan University

RCU. ò Dozens of supported file systems. ò Independent layer from backing storage. ò And, of course, networked file system support

Fall 2017 :: CSE 306. File Systems Basics. Nima Honarmand

Process Management 1

Processes COMPSCI 386

Contents. IPC (Inter-Process Communication) Representation of open files in kernel I/O redirection Anonymous Pipe Named Pipe (FIFO)

Operating Systems. Lecture 06. System Calls (Exec, Open, Read, Write) Inter-process Communication in Unix/Linux (PIPE), Use of PIPE on command line

Virtual File System. Don Porter CSE 506

Hyo-bong Son Computer Systems Laboratory Sungkyunkwan University

OS COMPONENTS OVERVIEW OF UNIX FILE I/O. CS124 Operating Systems Fall , Lecture 2

Process Management! Goals of this Lecture!

Contents. PA1 review and introduction to PA2. IPC (Inter-Process Communication) Exercise. I/O redirection Pipes FIFOs

Recitation 8: Tshlab + VM

CSE 333 SECTION 3. POSIX I/O Functions

IPC and Unix Special Files

Maria Hybinette, UGA. ! One easy way to communicate is to use files. ! File descriptors. 3 Maria Hybinette, UGA. ! Simple example: who sort

CS 201. Files and I/O. Gerson Robboy Portland State University

Preview. Interprocess Communication with Pipe. Pipe from the Parent to the child Pipe from the child to the parent FIFO popen() with r Popen() with w

Section 3: File I/O, JSON, Generics. Meghan Cowan

Lecture 2: Processes. CSE 120: Principles of Opera9ng Systems. UC San Diego: Summer Session I, 2009 Frank Uyeda

Inter-Process Communication

UNIX System Calls. Sys Calls versus Library Func

Assignment 1. Teaching Assistant: Michalis Pachilakis (

Applications of. Virtual Memory in. OS Design

File Systems. Jinkyu Jeong Computer Systems Laboratory Sungkyunkwan University

CSC209H Lecture 6. Dan Zingaro. February 11, 2015

Layers in a UNIX System. Create a new process. Processes in UNIX. fildescriptors streams pipe(2) labinstructions

CS 471 Operating Systems. Yue Cheng. George Mason University Fall 2017

Lecture 23: System-Level I/O

Windows architecture. user. mode. Env. subsystems. Executive. Device drivers Kernel. kernel. mode HAL. Hardware. Process B. Process C.

W4118 Operating Systems. Junfeng Yang

CSci 4061 Introduction to Operating Systems. IPC: Basics, Pipes

The Process Abstraction. CMPU 334 Operating Systems Jason Waterman

Processes. Processes (cont d)

Unix Processes. What is a Process?

ESE 333 Real-Time Operating Systems 2 What is an operating system? Two views: 1. Top-down view: Extended machine ffl Covers the details of the hardwar

SOFTWARE ARCHITECTURE 3. SHELL

ECE 650 Systems Programming & Engineering. Spring 2018

The course that gives CMU its Zip! I/O Nov 15, 2001

CMSC 216 Introduction to Computer Systems Lecture 17 Process Control and System-Level I/O

CPSC 341 OS & Networks. Processes. Dr. Yingwu Zhu

File Systems: Consistency Issues

CSE 410: Systems Programming

UNIVERSITY OF ENGINEERING AND TECHNOLOGY, TAXILA FACULTY OF TELECOMMUNICATION AND INFORMATION ENGINEERING SOFTWARE ENGINEERING DEPARTMENT

Inter-Process Communication. Disclaimer: some slides are adopted from the book authors slides with permission 1

File I/O and File Systems

CSE 333 SECTION 3. POSIX I/O Functions

Chapter 4. File Systems. Part 1

Data and File Structures Chapter 2. Basic File Processing Operations

CS 25200: Systems Programming. Lecture 14: Files, Fork, and Pipes

CSCE Operating Systems Interrupts, Exceptions, and Signals. Qiang Zeng, Ph.D. Fall 2018

System- Level I/O. Andrew Case. Slides adapted from Jinyang Li, Randy Bryant and Dave O Hallaron

System Calls and Signals: Communication with the OS. System Call. strace./hello. Kernel. Context Switch

UNIX System Programming. Overview. 1. A UNIX System. 2. Processes (review) 2.1. Context. Pipes/FIFOs

Prepared by Prof. Hui Jiang Process. Prof. Hui Jiang Dept of Electrical Engineering and Computer Science, York University

File Systems. Todays Plan. Vera Goebel Thomas Plagemann. Department of Informatics University of Oslo

Operating Systems. Review ENCE 360

CS 550 Operating Systems Spring Inter Process Communication

Process. Prepared by Prof. Hui Jiang Dept. of EECS, York Univ. 1. Process in Memory (I) PROCESS. Process. How OS manages CPU usage? No.

Operating Systems. Lecture 07. System Calls, Input/Output and Error Redirection, Inter-process Communication in Unix/Linux

RCU. ò Walk through two system calls in some detail. ò Open and read. ò Too much code to cover all FS system calls. ò 3 Cases for a dentry:

Logistics. Recitation 11: I/O Problems. Today s Plan. Why Use Robust I/O. Andrew Faulring Section A 18 November 2002

VFS, Continued. Don Porter CSE 506

Logical disks. Bach 2.2.1

Processes in linux. What s s a process? process? A dynamically executing instance of a program. David Morgan. David Morgan

Files and Directories

프로세스간통신 (Interprocess communication) i 숙명여대창병모

The Shell, System Calls, Processes, and Basic Inter-Process Communication

Operating System Structure

W4118: OS Overview. Junfeng Yang

628 Lecture Notes Week 4

Motivation. Operating Systems. File Systems. Outline. Files: The User s Point of View. File System Concepts. Solution? Files!

UNIX Sockets. COS 461 Precept 1

Goals of this Lecture

Processes. Operating System CS 217. Supports virtual machines. Provides services: User Process. User Process. OS Kernel. Hardware

Systems Programming. COSC Software Tools. Systems Programming. High-Level vs. Low-Level. High-Level vs. Low-Level.

CSE506: Operating Systems CSE 506: Operating Systems

I/O Management! Goals of this Lecture!

I/O Management! Goals of this Lecture!

Process Address Spaces and Binary Formats

Inter-process communication (IPC)

System Calls & Signals. CS449 Spring 2016

Lecture 4: Build Systems, Tar, Character Strings

Computer Systems Assignment 2: Fork and Threads Package

COSC Operating Systems Design, Fall Lecture Note: Unnamed Pipe and Shared Memory. Unnamed Pipes

everything is a file main.c a.out /dev/sda1 /dev/tty2 /proc/cpuinfo file descriptor int

Section 2: Processes

Interrupts, Fork, I/O Basics

UNIX Kernel. UNIX History

Transcription:

Basic OS Progamming Abstrac2ons Don Porter

Recap We ve introduced the idea of a process as a container for a running program And we ve discussed the hardware- level mechanisms to transi2on between the OS and applica2ons (interrupts) This lecture: Introduce key OS APIs Some may be familiar from lab 1 Others will help with lab 2

Outline Files and File Handles Inheritance Pipes Sockets Signals Synthesis Example: The Shell

2 Ways to Refer to a File Path, or hierarchical name, of the file Absolute: /home/porter/foo.txt Starts at system root Rela2ve: foo.txt Assumes file is in the program s current working directory Handle to an open file Handle includes a cursor (offset into the file)

Path- based calls Func2ons that operate on the directory tree Rename, unlink (delete), chmod (change permissions), etc. Open creates a handle to a file int open (char *path, int flags, mode_t mode); Flags include O_RDONLY, O_RDWR, O_WRONLY Permissions are generally checked only at open Opendir variant for a directory

Handle- based calls ssize_t read (int fd, void *buf, size_t count) Fd is the handle Buf is a user- provided buffer to receive count bytes of the file Returns how many bytes read ssize_t write(int fd, void *buf, size_t count) Same idea, other direc2on int close (int fd) Close an open file

Example char buf[9]; // stack allocate a char buffer int fd = open ( foo.txt, O_RDWR); ssize_t bytes = read(fd, buf, 8); if (bytes!= 8) // handle the error memset (buf, Awesome, 7); buf[7] = \0 ; bytes = write(fd, buf, 8); if (bytes!= 8) // error close(fd);

But what is a handle? A reference to an open file or other OS object For files, this includes a cursor into the file In the applica2on, a handle is just an integer This is an offset into an OS- managed table

Handles can Logical be View shared Virtual Address Space Hello! Foo.txt inode 50 Handle Table Process A Handle indices are process- specific 20 Process B Disk Handle Table Process C

Handle Recap Every process has a table of pointers to kernel handle objects E.g., a file handle includes the offset into the file and a pointer to the kernel- internal file representa2on (inode) Applica2on s can t directly read these pointers Kernel memory is protected Instead, make system calls with the indices into this table Index is commonly called a handle

Rearranging the table The OS picks which index to use for a new handle An applica2on explicitly copy an entry to a specific index with dup2(old, new) Be careful if new is already in use

Other useful handle APIs We ve seen mmap already; can map part or all of a file into memory seek() adjust the cursor posi2on of a file Like rewinding a cassege tape

Outline Files and File Handles Inheritance Pipes Sockets Signals Synthesis Example: The Shell

Inheritance By default, a child process gets a copy of every handle the parent has open Very convenient Also a security issue: may accidentally pass something the program shouldn t Between fork() and exec(), the parent has a chance to clean up handles it doesn t want to pass on See also CLOSE_ON_EXEC flag

Standard in, out, error Handles 0, 1, and 2 are special by conven2on 0: standard input 1: standard output 2: standard error (output) Command- line programs use this conven2on Parent program (shell) is responsible to use open/close/ dup2 to set these handles appropriately between fork() and exec()

int pid = fork(); if (pid == 0) { Example int input = open ( in.txt, O_RDONLY); } // dup2(input, 0); exec( grep, quack );

Outline Files and File Handles Inheritance Pipes Sockets Signals Synthesis Example: The Shell

Pipes FIFO stream of bytes between two processes Read and write like a file handle But not anywhere in the hierarchical file system And not persistent And no cursor or seek()- ing Actually, 2 handles: a read handle and a write handle Primarily used for parent/child communica2on Parent creates a pipe, child inherits it

Example int pipe_fd[2]; int rv = pipe(pipe_fd); int pid = fork(); if (pid == 0) { close(pipe_fd[1]); //Close unused write end dup2(pipe_fd[0], 0); // Make the read end stdin exec( grep, quack ); } else { close (pipe_fd[0]); // Close unused read end

Sockets Similar to pipes, except for network connec2ons Setup and connec2on management is a bit trickier A topic for another day (or class)

Select What if I want to block un2l one of several handles has data ready to read? Read will block on one handle, but perhaps miss data on a second Select will block a process un2l a handle has data available Useful for applica2ons that use pipes, sockets, etc.

Outline Files and File Handles Inheritance Pipes Sockets Signals Synthesis Example: The Shell

Signals Similar concept to an applica2on- level interrupt Unix- specific (more on Windows later) Each signal has a number assigned by conven2on Just like interrupts Applica2on specifies a handler for each signal OS provides default If a signal is received, control jumps to the handler If process survives, control returns back to applica2on

Signals, cont. Can occur for: Excep2ons: divide by zero, null pointer, etc. IPC: Applica2on- defined signals (USR1, USR2) Control process execu2on (KILL, STOP, CONT) Send a signal using kill(pid, signo) Killing an errant program is common, but you can also send a non- lethal signal using kill() Use signal() or sigac2on() to set the handler for a signal

How signals work Although signals appear to be delivered immediately They are actually delivered lazily Whenever the OS happens to be returning to the process from an interrupt, system call, etc. So if I signal another process, the other process may not receive it un2l it is scheduled again Does this mager?

More details When a process receives a signal, it is added to a pending mask of pending signals Stored in PCB Just before scheduling a process, the kernel checks if there are any pending signals If so, return to the appropriate handler Save the original register state for later When handler is done, call sigreturn() system call Then resume execu2on

Laziness rules! Not on homework But in system design Meta- lesson Procras2na2ng on work in the system olen reduces overall effort Signals: Why context switch immediately when it will happen soon enough?

Language Excep2ons Signals are the underlying mechanism for Excep2ons and catch blocks JVM or other run2me system sets signal handlers Signal handler causes execu2on to jump to the catch block

Windows comparison Excep2ons have specific upcalls from the kernel to ntdll IPC is done using Events Shared between processes Handle in table No data, only 2 states: set and clear Several variants: e.g., auto- clear aler checking the state

Outline Files and File Handles Inheritance Pipes Sockets Signals Synthesis Example: The Shell

Shell Recap Almost all commands are really binaries /bin/ls Key abstrac2on: Redirec2on over pipes >, <, and implemented by the shell itself

Ex: ls grep foo Implementa2on sketch: Shell Example Shell parses the en2re string Sets up chain of pipes Forks and exec s ls and grep separately Wait on output from grep, print to console

What about Ctrl- Z? Shell really uses select() to listen for new keystrokes (while also listening for output from subprocess) Special keystrokes are intercepted, generate signals Shell needs to keep its own scheduler for background processes Assigned simple numbers like 1, 2, 3 fg 3 causes shell to send a SIGCONT to suspended child

Other hints Splice(), tee(), and similar calls are useful for connec2ng pipes together Avoids copying data into and out- of applica2on

Summary Understand how handle tables work Survey basic APIs Understand signaling abstrac2on Intui2on of how signals are delivered Be prepared to start wri2ng your shell in lab 2!