CSE350 Software Design and Engineering University of Pennsylvania Professor Jonathan M. Smith Office: 254 Moore GRW, Phone: January 9th, 2001

Administrative lFirst group assignment Tuesday, 1/15 lGroups will be formed today lWe will use as the class web site lIt’s currently outdated – will fix

What is an operating system? lAn operating system manages hardware resources lTypically, for multiple users lProtection, services such as file systems (structure), concurrent execution, buffering, etc. lIn UNIX (for example), OS functions are privileged – behind a protection boundary

The Unix Time-sharing System (slides from J.R. Davin) lD. M. Ritchie and K. Thompson. The Unix time-sharing system. BSTJ, 57:6 (July-August, 1978), lK. Thompson. Unix implementation. BSTJ, 57:6 (July-August, 1978),

Features lA hierarchical filesystem incorporating demountable volumes lCompatible file, device, interprocess communication lThe ability to initiate asynchronous processes lSystem command language selectable on a per-user basis lOver 100 subsystems including a dozen languages lHigh degree of portability

Economics of the 1970s lHardware cost: $40,000 lSoftware cost: two man-years lCost recovery for disk space

PDP-11/70 Platform l16-bit word (8-bit byte) l768 KBytes core memory lSystem kernel 90 KBytes lMinimal system 96 Kbytes lTwo 200 MByte moving-head disks l20 variable speed (300 to 1200 baud) communication interfaces l12 communication lines (9600 baud) lSynchronous interfaces (2400 and 4800 baud) for inter-machine file transfer lNine-track tape, line printer, phototypesetter lVoice synthesizer, digital switching network, chess machine

A Unix System in 1978 lUser population: 125 lMaximum simultaneous users: 33 lDirectories: 1630 lFiles: lDisk blocks (512-byte) used: 301,700 lDaily command invocations: lDaily (non-idle) CPU hours: 9.6 lDaily connect hours: 230

The C Programming Language lSystem re-coded in C in summer, 1973 l1/3 bigger than assembler language version

Observation "The most important role of the system is to provide a file system." (Page 1907)

Filesystem Properties lInternal file structure controlled by application programs lInternal file structure not imposed by system lHierarchy lDirectories as files l"." and ".." convention lLinks lRestrictions on namespace topology lMountable volumes

File Types lOrdinary lDirectory lSpecial Character Block

Filesystem Representation li-Number li-List li-Node

File Properties lOwner user-id lOwner group-id lProtection bits lPhysical disk (or tape) address of contents lSize lTime of creation lTime of last use lTime of last modification lNumber of links lFile type

File Protection lUser (owner) read, write, execute lGroup read, write, execute lOthers read, write, execute lSet-user-id --drwxwrxrwx l"Execute" permission on directories

Filesystem API lfilep = open (name, flag) lfilep = creat (name) ln = read (filep, buffer, count) ln = write (filep, buffer, count) llocation = lseek (filep, offset, base)

Why file descriptors? Consider open(“/home/jms/cse350.txt”) Consider read(“/home/jms/cse350.txt”) open() happens once, read() many times Pay cost of name lookup, permissions checks (existence!) at open(), reuse results, repetitively, at read() open() returns a descriptor, used by read()

Example: copy a file from one place to another main() { char c; int r_fd = 0, w_fd = 1; while( read(r_fd, &c, 1) > 0 ) write(w_fd, &c, 1); }

Crossing protection boundary lHow does a program access services? lIt does so through entry points called system calls These include read(), write(), open(), close() and creat() lAppear to be subroutines calls in “C”

File Space Management lBlocks 0 through 9 indicated in i-node lBlocks 10 through 137 indicated indirectly lBlocks 138 through indicated doubly indirectly lBlocks and higher indicated triply indirectly Performance Techniques: caching and read- ahead

Special File Naming Example Name: /dev/foo lMajor Device Number: selects driver code lMinor Device Number: selects device instance within class

File System Data Structure

Process Management API lprocessid = fork () lexecute (file, arg1,..., argN) lprocessid = wait (& status) lexit (status) lfilep = pipe () lTraps, Signals lMinimalist, integrated process synchronization

Process Control Data Structure

The Shell and Reusability lRedirection lStdin, stdout, stderr lPipes and filters lArgument parsing and globbing lMultitasking lBasic control structures

Perspective "The success of the Unix system is largely due to the fact that it was not designed to meet any predefined objectives.“ (Page 1926) Motivation: dissatisfaction with existing facilities.

Retrospective Design Considerations lEasy to write, test, run programs Interactive use lConstraints on size lSelf-maintenance Available source code

Easy Programming lDevice-independent file abstraction lNo "access methods" lFew system constraints on program

Influences lfork () from GENIE time-sharing system lI/O API from Multics lShell concept from Multics lImplementing "system" code as user primitives from Multics

Unix Implementation l10,000 lines of C code l1,000 lines of assembler code 800 lines not possible in C 200 lines for efficiency

Observation "Throughout, simplicity has been substituted for efficiency." (Page 1932)

Observation "The UNIX kernel is an I/O multiplexer more than a complete operating system. This is as it should be." (Page 1945)

Unsupported (unwanted?) features: lFile access methods lFile disposition lFile formats lFile maximum size lSpooling lCommand language lLogical records lPhysical records lLogical file names lMultiple character sets lOperator and operator console lLogin and logout