✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ I/O: A Typical Hardware System I/O: A Typical Hardware System CS 105 CPU chip “Tour of the Black Holes of Computing” register file ALU Input and Output Input and Output system bus memory bus main I/O bus interface bridge memory Topics I/O hardware Unix file abstraction I/O bus Expansion slots for Robust I/O other devices such as network adapters. USB graphics disk File sharing controller adapter controller mousekeyboard monitor disk CS 105 – 2 – Abstracting I/O Abstracting I/O Unix Files Unix Files Low level requires complex device commands A Unix file is a sequence of m bytes: Vary from device to device B 0 , B 1 , .... , B k , .... , B m-1 Device models can be very different � Tape: read or write sequentially, or rewind Cool fact: All I/O devices are represented as files: � Disk: “random” access at block level /dev/sda1 ( /boot disk partition) � Terminal: sequential, no rewind, must echo and allow editing /dev/tty2 (terminal) � Video: write-only, with 2-dimensional structure Operating system should hide these differences Even the kernel is represented as files: “Read” and “write” should work regardless of device /dev/kmem (access to kernel memory) Sometimes impossible to generalize (e.g., video) /proc (kernel data structures) Still need access to full power of hardware /sys (device discovery and control) CS 105 CS 105 – 3 – – 4 –
✁ ✁ ✄ ✆ ✂ ✁ ✁ ✁ ✁ � ✁ ✂ � ✁ � ✁ � ✁ ✁ ✁ ✁ ✄ ✁ ☎ ✂ ✁ ✁ ✁ ✁ ✄ Unix I/O Overview Unix I/O Overview Regular Files Regular Files A regular file contains arbitrary data Elegant mapping of files to devices allows kernel to export a simple interface called Unix I/O Applications often distinguish between text files and binary files Text files are regular files with only ASCII or Unicode characters Key Unix idea: All input and output is handled in a consistent and uniform Binary files are everything else way e.g., object files, JPEG images Basic Unix I/O operations (system calls): Kernel doesn’t know the difference! Opening and closing files: open() and close() Text file is sequence of text lines Text line is sequence of chars terminated by newline character (‘ \n ’) Reading and writing a file: read() and write() Newline is 0xa , same as ASCII line feed character (LF) Changing the current file position (seek): lseek (not discussed) Note that a proper text file always ends with a newline! End of line (EOL) indicators in other systems � � ����� � � � ����� Linux and Mac OS: '\n' ( 0xa ) line feed (LF) Windows and Internet protocols: '\r' '\n' ( 0xd 0xa ) ������������������������� Carriage return (CR) followed by line feed (LF) CS 105 CS 105 – 5 – – 7 – Directories Directories Directory Hierarchy Directory Hierarchy All files are organized as a hierarchy anchored by root directory named / Directory consists of a dictionary of links (slash) Each link maps a filenam e to a file / Each directory contains at least two entries . (dot) is a link to itself bin/ dev/ etc/ home/ usr/ .. (dot dot) is a link to the parent directory in the directory hierarchy (next slide) Commands for manipulating directories bash tty1 group passwd geoff/ z/ include/ bin/ mkdir : create empty directory ls : view directory contents foo.c stdio.h sys/ emacs rmdir : delete empty directory unistd.h Kernel maintains current working directory (cwd) for each process Modified using the cd command CS 105 CS 105 – 8 – – 9 –
✁ � ✁ ✁ � � � ✁ � ✁ � � � ✁ ✁ � ✁ ✁ Pathnames Pathnames Opening Files Opening Files #include <errno.h> ... Locations of files in the hierarchy denoted by pathnames int fd; /* file descriptor */ Absolute pathname starts with ‘/’ and denotes path from root fd = open("/etc/hosts", O_RDONLY); � /home/geoff/foo.c if (fd == -1) { Relative pathname denotes path from current working directory fprintf(stderr, "Couldn’t open /etc/hosts: %s", strerror(errno)); exit(1); � ../geoff/foo.c / Opening a file tells kernel you are getting ready to access it cwd: /home/z Returns small identifying integer file descriptor bin/ dev/ etc/ home/ usr/ fd == -1 indicates that an error occurred; errno has reason strerror converts to English (Note: use strerror_r for thread safety) bash tty1 group passwd geoff/ z/ include/ bin/ Each process created by a Unix shell begins life with three open files (normally connected to terminal): foo.c stdio.h sys/ emacs 0: standard input 1: standard output 2: standard error unistd.h CS 105 CS 105 – 10 – – 11 – Redirecting Files Redirecting Files Closing Files Closing Files int fd; /* file descriptor */ One of the most powerful ideas in Unix int retval; /* return value */ You can easily redirect stdin/stdout/stderr if ((retval = close(fd)) == -1) { ./echoclient < /etc/passwd redirects input perror("close"); grep knuth /etc/hosts > ~/knuthip redirects output exit(1); ls –Rl /proc 2> /dev/null redirects error } You can even hook programs together (“piping”): Closing a file tells kernel that you’re finished with it find / -name core | wc -l find / -name core –print0 | xargs -0 rm –f Closing an already closed file is recipe for disaster in threaded programs You’re not true Unix expert until you’re good with pipes (more on this later) Two-command pipes: advanced learner Three commands: excellent competence Some error reports are delayed until close! Six or more: scary ninja cat foo | bar is always incorrect (and sign of ignorance) Moral: Always check return codes, even for seemingly benign functions Use bar < foo instead such as close() Don’t let stackoverflow fool you! perror is simplified strerror/fprintf ; see man page CS 105 CS 105 – 12 – – 13 –
✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ ✁ Reading Files Reading Files Writing Files Writing Files char buf[4096]; char buf[4096]; int fd; /* file descriptor */ int fd; /* file descriptor */ unsigned int nbytes; /* number of bytes read */ unsigned int nbytes; /* number of bytes read */ /* Open the file fd ... */ /* Open file fd ... */ /* Then write up to 4096 bytes from buf to file fd */ /* Then read up to 4096 bytes from file fd */ if ((nbytes = write(fd, buf, sizeof buf) == -1) { if ((nbytes = read(fd, buf, sizeof buf)) == -1) { perror("write"); perror("read"); exit(1); exit(1); } } Writing a file copies bytes from memory to current file position , then updates current file Reading a file copies bytes from current file position into memory, then updates file position position Returns number of bytes written from buf to file fd You must provide the memory (buffer) nbytes == -1 indicates that an error occurred Returns number of bytes read from file fd into buf nbytes == 0 will never happen nbytes == -1 indicates error occurred As with reads, short counts are possible and are not errors! nbytes == 0 indicates end of file (EOF) This example transfers up to 4096 bytes from address buf to file fd Short counts ( nbytes < sizeof buf ) are possible and are not errors! CS 105 CS 105 – 14 – – 15 – Simple Unix I/O Example Simple Unix I/O Example Dealing with Short Counts Dealing with Short Counts Short counts can occur in these situations: #include "csapp.h" Encountering (end-of-file) EOF on reads int main(void) Reading text lines from a terminal { char c; Reading and writing network sockets or Unix pipes while(Read(STDIN_FILENO, &c, 1) > 0) Short counts never occur in these situations: Write(STDOUT_FILENO, &c, 1); exit(0); Reading from disk files, except for EOF } Writing to disk files (Inefficiently) copies standard input to standard output one byte at a time How should you deal with short counts in your code? (basically, this is cat ) Use the RIO (Robust I/O) package from your textbook’s csapp.c file (Appendix B) � (But note that it handles EOF wrong on terminal) Note the use of error-handling wrappers for read and write (Appendix B in Use C stdio or C++ streams (also sometimes blows EOF!) text) Write your code very, very carefully Ignore the problem and accept that your code is fragile CS 105 CS 105 – 16 – – 17 –
Recommend
More recommend
