SlideServe
Menu
Préférences
© SlideServe · v2026

CSE350 Software Design and Engineering

nickolas-macris avatar
33 diapositives · 490 Views · Dec 01, 2014

CSE350 Software Design and Engineering. University of Pennsylvania Professor Jonathan M. Smith http://www.cis.upenn.edu/~jms Office: 254 Moore GRW, Phone: 8-9509 January 9th, 2001. Administrative. First group assignment Tuesday, 1/15 Groups will be formed today

CSE350 Software Design and Engineering - slide 1
01 / 33CSE350 Software Design and Engineering
1 / 17

Télécharger la présentation

CSE350 Software Design and Engineering
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  1. CSE350 Software Design and Engineering University of Pennsylvania Professor Jonathan M. Smith http://www.cis.upenn.edu/~jms Office: 254 Moore GRW, Phone: 8-9509 January 9th, 2001

  2. Administrative • First group assignment Tuesday, 1/15 • Groups will be formed today • We will use http://www.cis.upenn.edu/~cse350 as the class web site • It’s currently outdated – will fix

  3. What is an operating system? • An operating system manages hardware resources • Typically, for multiple users • Protection, services such as file systems (structure), concurrent execution, buffering, etc. • In UNIX (for example), OS functions are privileged – behind a protection boundary

  4. The Unix Time-sharing System(slides from J.R. Davin) • D. M. Ritchie and K. Thompson. • The Unix time-sharing system. • BSTJ, 57:6 (July-August, 1978), 1905-1929. • K. Thompson. • Unix implementation. • BSTJ, 57:6 (July-August, 1978), 1931-1946.

  5. Features • A hierarchical filesystem incorporating demountable volumes • Compatible file, device, interprocess communication • The ability to initiate asynchronous processes • System command language selectable on a per-user basis • Over 100 subsystems including a dozen languages • High degree of portability

  6. Economics of the 1970s • Hardware cost: $40,000 • Software cost: two man-years • Cost recovery for disk space

  7. PDP-11/70 Platform • 16-bit word (8-bit byte) • 768 KBytes core memory • System kernel 90 KBytes • Minimal system 96 Kbytes • Two 200 MByte moving-head disks • 20 variable speed (300 to 1200 baud) communication interfaces • 12 communication lines (9600 baud) • Synchronous interfaces (2400 and 4800 baud) for inter-machine file transfer • Nine-track tape, line printer, phototypesetter • Voice synthesizer, digital switching network, chess machine

  8. A Unix System in 1978 • User population: 125 • Maximum simultaneous users: 33 • Directories: 1630 • Files: 28300 • Disk blocks (512-byte) used: 301,700 • Daily command invocations: 13500 • Daily (non-idle) CPU hours: 9.6 • Daily connect hours: 230

  9. The C Programming Language • System re-coded in C in summer, 1973 • 1/3 bigger than assembler language version

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

  11. Filesystem Properties • Internal file structure controlled by application programs • Internal file structure not imposed by system • Hierarchy • Directories as files • "." and ".." convention • Links • Restrictions on namespace topology • Mountable volumes

  12. File Types • Ordinary • Directory • Special • Character • Block

  13. Filesystem Representation • i-Number • i-List • i-Node

  14. File Properties • Owner user-id • Owner group-id • Protection bits • Physical disk (or tape) address of contents • Size • Time of creation • Time of last use • Time of last modification • Number of links • File type

  15. File Protection • User (owner) read, write, execute • Group read, write, execute • Others read, write, execute • Set-user-id --drwxwrxrwx • "Execute" permission on directories

  16. Filesystem API • filep = open (name, flag) • filep = creat (name) • n = read (filep, buffer, count) • n = write (filep, buffer, count) • location = lseek (filep, offset, base)

  17. 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()

  18. 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); }

  19. Crossing protection boundary • How does a program access services? • It does so through entry points called system calls • These include read(), write(), open(),close() and creat() • Appear to be subroutines calls in “C”

  20. File Space Management • Blocks 0 through 9 indicated in i-node • Blocks 10 through 137 indicated indirectly • Blocks 138 through 16521 indicated doubly indirectly • Blocks 16522 and higher indicated triply indirectly Performance Techniques: caching and read-ahead

  21. Special File Naming • Example Name: /dev/foo • Major Device Number: selects driver code • Minor Device Number: selects device instance within class

  22. File System Data Structure

  23. Process Management API • processid = fork () • execute (file, arg1, ..., argN) • processid = wait (& status) • exit (status) • filep = pipe () • Traps, Signals • Minimalist, integrated process synchronization

  24. Process Control Data Structure

  25. The Shell and Reusability • Redirection • Stdin, stdout, stderr • Pipes and filters • Argument parsing and globbing • Multitasking • Basic control structures

  26. 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.

  27. Retrospective Design Considerations • Easy to write, test, run programs • Interactive use • Constraints on size • Self-maintenance • Available source code

  28. Easy Programming • Device-independent file abstraction • No "access methods" • Few system constraints on program

  29. Influences • fork () from GENIE time-sharing system • I/O API from Multics • Shell concept from Multics • Implementing "system" code as user primitives from Multics

  30. Unix Implementation • 10,000 lines of C code • 1,000 lines of assembler code • 800 lines not possible in C • 200 lines for efficiency

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

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

  33. Unsupported (unwanted?) features: • File access methods • File disposition • File formats • File maximum size • Spooling • Command language • Logical records • Physical records • Logical file names • Multiple character sets • Operator and operator console • Login and logout