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

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

Preview. System Call. System Call. System Call. System Call. Library Functions 9/20/2018. System Call

Lecture files in /home/hwang/cs375/lecture05 on csserver.

File I/0. Advanced Programming in the UNIX Environment

I/O OPERATIONS. UNIX Programming 2014 Fall by Euiseong Seo

I/O OPERATIONS. UNIX Programming 2014 Fall by Euiseong Seo

Operating System Labs. Yuanbin Wu

Hyo-bong Son Computer Systems Laboratory Sungkyunkwan University

Goals of this Lecture

I/O Management! Goals of this Lecture!

I/O Management! Goals of this Lecture!

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

How do we define pointers? Memory allocation. Syntax. Notes. Pointers to variables. Pointers to structures. Pointers to functions. Notes.

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

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

Lecture 3. Introduction to Unix Systems Programming: Unix File I/O System Calls

Naked C Lecture 6. File Operations and System Calls

UNIX System Programming

CMPS 105 Systems Programming. Prof. Darrell Long E2.371

CSC 271 Software I: Utilities and Internals

Lecture 21 Systems Programming in C

Process Management! Goals of this Lecture!

CSE 333 SECTION 3. POSIX I/O Functions

CS240: Programming in C

Operating systems. Lecture 7

Advanced Unix/Linux System Program. Instructor: William W.Y. Hsu

Input and Output System Calls

Physical Files and Logical Files. Opening Files. Chap 2. Fundamental File Processing Operations. File Structures. Physical file.

CSE 410: Systems Programming

CMPSC 311- Introduction to Systems Programming Module: Input/Output

Unix File and I/O. Outline. Storing Information. File Systems. (USP Chapters 4 and 5) Instructor: Dr. Tongping Liu

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

UNIX input and output

Summer June 15, 2010

System Calls and I/O Appendix. Copyright : University of Illinois CS 241 Staff 1

Operating System Labs. Yuanbin Wu

UNIX System Calls. Sys Calls versus Library Func

Process Creation in UNIX

Recitation 8: Tshlab + VM

CSE 333 SECTION 3. POSIX I/O Functions

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

System Calls and I/O. CS 241 January 27, Copyright : University of Illinois CS 241 Staff 1

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

What Is Operating System? Operating Systems, System Calls, and Buffered I/O. Academic Computers in 1983 and Operating System

PRACTICAL NO : 1. AIM: To study various file management system calls in UNIX.

Data and File Structures Chapter 2. Basic File Processing Operations

Files. Eric McCreath

Princeton University Computer Science 217: Introduction to Programming Systems. I/O Management

Princeton University. Computer Science 217: Introduction to Programming Systems. I/O Management

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

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

All the scoring jobs will be done by script

CS 33. Shells and Files. CS33 Intro to Computer Systems XX 1 Copyright 2017 Thomas W. Doeppner. All rights reserved.

CSC209H Lecture 6. Dan Zingaro. February 11, 2015

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

Chapter 3. File I/O. System Programming 熊博安國立中正大學資訊工程學系

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

CSCE 313 Introduction to Computer Systems. Instructor: Dezhen Song

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

Inter-Process Communication

OPERATING SYSTEMS: Lesson 2: Operating System Services

Princeton University Computer Science 217: Introduction to Programming Systems I/O Management

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

CS 33. Files Part 2. CS33 Intro to Computer Systems XXI 1 Copyright 2018 Thomas W. Doeppner. All rights reserved.

Chapter 10. The UNIX System Interface

Files and the Filesystems. Linux Files

Introduction. Files. 3. UNIX provides a simple and consistent interface to operating system services and to devices. Directories

CSE 410: Systems Programming

Outline. Relationship between file descriptors and open files

UNIX Kernel. UNIX History

File Descriptors and Piping

Computer Architecture and System Programming Laboratory. TA Session 5

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

File I/O. Dong-kun Shin Embedded Software Laboratory Sungkyunkwan University Embedded Software Lab.

CS240: Programming in C

All the scoring jobs will be done by script

Computer Architecture and Assembly Language. Practical Session 5

UNIX I/O. Computer Systems: A Programmer's Perspective, Randal E. Bryant and David R. O'Hallaron Prentice Hall, 3 rd edition, 2016, Chapter 10

UNIX System Overview E. Im

Processes COMPSCI 386

Files and Directories

Creating a Shell or Command Interperter Program CSCI411 Lab

Standard I/O in C, Computer System and programming in C

Network Socket Programming - 1 BUPT/QMUL

Lecture 3: System Calls & API Standards

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

DEPT OF ISE, NIT,RAICHUR Page 1

Preview. Process Control. What is process? Process identifier The fork() System Call File Sharing Race Condition. COSC350 System Software, Fall

File Systems. Jinkyu Jeong Computer Systems Laboratory Sungkyunkwan University

POSIX Shared Memory. Linux/UNIX IPC Programming. Outline. Michael Kerrisk, man7.org c 2017 November 2017

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

ECE 650 Systems Programming & Engineering. Spring 2018

Input/Output. Input/Output and Files. Input/Output. I/O System Objectives

Introduction to File Systems. CSE 120 Winter 2001

628 Lecture Notes Week 4

which maintain a name to inode mapping which is convenient for people to use. All le objects are

File I/O - Filesystems from a user s perspective

K.I.S.S. Keep It Simple, Stupid! Outline. Unix System Programming. UNIX History. UNIX History (cont) UNIX Today. What Unix Gets Wrong (Raymond)

Operating Systems CMPSCI 377 Spring Mark Corner University of Massachusetts Amherst

Contents. Programming Assignment 0 review & NOTICE. File IO & File IO exercise. What will be next project?

Transcription:

Systems Programming COSC 2031 - Software Tools Systems Programming (K+R Ch. 7, G+A Ch. 12) The interfaces we use to work with the operating system In this case: Unix Programming at a lower-level Systems Programming High-Level vs. Low-Level The interfaces here are Unix-specific (i.e. they may not exist on other platforms) They are also low-level interfaces In many cases, other functions you use (e.g. printf) are built on top of these functions Your program C Library Unix interface read_dict("words") f("words","r") ("words",o_rdonly) kernel actual work is done here High-Level vs. Low-Level Higher-level interfaces tend to be more abstract/generalized simpler to program but less powerful more standard (e.g. Standard C Library) Lower-level interfaces tend to be more specific harder to work with but more powerful potentially more efficient System Calls System calls are functions under Unix which are implemented in the kernel See section 2 of the manual pages e.g. chdir(2) - changes the current working directory (like "cd" command) your program calls this function in C, but the kernel does the real work 1

File Descriptors At the Unix level files are represented by integers called file descriptors For what we will talk about next we need: #include <unistd.h> #include <fcntl.h> read There are two main system calls for input and output int read(int fd, void *buf, int n) Reads n bytes from the file descriptor fd and stores the bytes at the address pointed to by buf Returns number of bytes read or <0 on an error write The write call is similar int write(int fd, void *buf, int n) Same as read() except that n bytes starting at address buf are written to file descriptor fd Opens a file for input and/or output int (char *path, int flags, int mode) path is obvious - it's the name of the file you want to work with flags is a set of bits (remember the C bitwise operators?) that describes how we will work with the file flags is a bitwise-or of several predefined constants flags O_RDONLY - file in read-only mode O_WRONLY - file in write-only mode O_RDWR - file for reading and writing O_CREAT - create file if it does not exist O_APPEND - all writes are made to the end of the file O_EXCL - (only with O_CREAT) - fails if file already exists 2

mode is the set of default permissions for the file as an integer Again these permissions are bits POSIX defines constants (<sys/stat.h>) S_IRUSR - read-permission (owner) S_IWGRP - write-permission (group) S_IXOTH - execute-permission (other) modes The values of the modes are so common that we often use the absolute values: 0100 - user exec 0010 - group exec 0200 - user write 0020 - group write 0400 - user read 0040 - group read 0001 - other exec 0002 - other write 0004 - other read So: ("foobar",o_creat O_WRONLY, 0644); would attempt to "foobar" for writing. If "foobar" didn't exist it would try to create the file with permissions "0644" Note that if we are not using O_CREAT then we do not need to give the "mode" argument: ("foobar",o_rdonly); is okay close When we are done with a file descriptor, we close it: int close(int fd); vs. f? calling () always switches control to the operating system [system call] making a system call has overhead (i.e. time required for making any system call) f() may buffer data in memory Try the example /cs/course/2031/.c 3

vs. f? f() actually uses () to actually a file With f() you also have fgetc(), fgets() With () you only have read(), write() However () is more flexible (O_CREAT, O_EXCL, specifying mode) We saw how to do temporary files in the shell, but how do we do them in C? See standard functions tmpfile(3c) and tmpnam(3c) Let's see how they would work Recall from our shell discussion gettemp() { id=0 while [ -f $1.$$.$id ]; do id=`expr $id + 1` done echo $1.$$.$id } Here we test to see if the file exists We can do something similar with First our variables: int gettemp(char *base) { char tmp[256]; int pid = (int)getpid(); int cnt = 0, fd; do { sprintf(tmp,"%s.%d.%d",base, pid,cnt++); fd = (tmp, O_RDWR O_CREAT O_TRUNC, 0600); } while (fd < 0); return fd; Note that we do not return a file name but a file descriptor We can then work with that file descriptor with read(2) and write(2) But what if we want to write some data to the temporary file and then read it back? 4

lseek The lseek(2) call allows us to set the position of a file descriptor in the file int lseek(int fd, int offset, int whence); whence is one of SEEK_SET - offset is from the start of the file SEEK_CUR - offset is from the current position SEEK_END - offset is from the end of the file lseek Example: lseek(5, 0, SEEK_SET); sets the position of file descriptor 5 to an offset of 0 from the beginning of the file (SEEK_SET). In other words, the next byte read from the file will come from the beginning of the file Temporary Files + lseek int fd; fd = gettemp("/tmp/work"); write(fd,data,10000); lseek(fd,0,seek_set); /* now we can read the data back */ read(fd,newdata,10000); vs. f again There are similar functions for f()-type files (see rewind(3c) and fseek(3c)) What if we really want to process a file descriptor's data one byte at a time? We can use successive calls to read() or fd FILE *fd(int fd, char *mode); Like f() but takes a file descriptor instead of a file name You can then use getc(), putc(), etc. on the returned FILE object File Descriptors vs. Files A file or a stream is a sequence of bytes Think of a file descriptor as a one point-ofview of a file You can the same file twice (different file descriptors) Different file descriptors can be at different positions in a file (even if they refer to the same file) 5

File Descriptors vs. Files An example: int fd1, fd2; fd1 = ("foobar",o_rdonly); fd2 = ("foobar",o_rdonly); lseek(fd1,1000,seek_set); This is valid and creates two file descriptors foobar: So what happens? 0 1 2 999 1000 1001 fd2 read(fd1,buf,5); fd1 0 1 2 999 1000 1001 fd2 fd1 Note that fd2's position is unaffected by fd1 1005 fd1 dup dup2 We can make a copy of a file descriptor int dup(int fd); Returns a new file descriptor which is a copy of the file descriptor fd (points to the same thing at the same location) A more useful variation on this is called dup2: int dup2(int fd, int nfd); Tries to create a copy of file descriptor fd with the new file descriptor id nfd. (Like dup() except you get to choose what the new file descriptor number is.) Back to the Bourne shell Remember this? command 2>file Executes command and redirects stderr to the file named file. The "2>" syntax means "redirect file descriptor 2" Standard File Descriptors The following file descriptor values are considered standard: 0 = stdin 1 = stdout 2 = stderr So write(1,buf,n); writes n bytes from address buf to stdout 6

To Think About File descriptors can refer to more than just files. They can also refer to pipes between programs, network connections, etc. [More on this next day.] Play around with the "truss" program in the Prism lab (traces system calls). For example, try: truss echo hi Try it on other commands too. 7