eo 253 operating systems
play

EO-253 Operating Systems Instructor: Vinod Ganapathy IISc Slide - PowerPoint PPT Presentation

EO-253 Operating Systems Instructor: Vinod Ganapathy IISc Slide credits: David Mazieres (Stanford University) 1 / 33 Outline Administrivia 1 2 Substance 2 / 33 Administrivia Class web page:


  1. EO-253 – Operating Systems Instructor: Vinod Ganapathy IISc Slide credits: David Mazieres (Stanford University) 1 / 33

  2. Outline Administrivia 1 2 Substance 2 / 33

  3. Administrivia • Class web page: http://www.csa.iisc.ac.in/~vg/teaching/E0-253 - All assignments, handouts, lecture notes on-line • Textbook: Operating Systems: Three Easy Pieces, Remzi and Andrea Arpaci-Dusseau • Goal is to make lecture slides the primary reference - Almost everything I talk about will be on slides - PDF slides contain links to further reading about topics - Please download slides from class web page 3 / 33

  4. Course topics • Threads & Processes • Concurrency & Synchronization • Scheduling • Virtual Memory • I/O • Disks, File systems • Protection & Security • Virtual machines • Note: Lectures will ofen take Unix as an example - Most current and future OSes heavily influenced by Unix - Won’t talk much about Windows 4 / 33

  5. Course goals • Introduce you to operating system concepts - Hard to use a computer without interacting with OS - Understanding the OS makes you a more effective programmer • Cover important systems concepts in general - Caching, concurrency, memory management, I/O, protection • Teach you to deal with larger sofware systems - Programming assignments much larger than many courses - Warning: Many people will consider course very hard - Expect to spend about ≥ 15 hours/week 5 / 33

  6. Programming Assignments • Implement parts of Pintos operating system - Built for x86 hardware, you will use hardware emulator • Four implementation projects: - Threads - User processes - Virtual memory - File system • Implement projects individually 6 / 33

  7. Grading • Labs: 40% - For each lab, 50% of score based on passing test cases - Remaining 50% based on design and style • Most people’s labs pass most test cases - Please, please, please turn in working code, or no credit here • Means design and style matter a lot - Large sofware systems not just about producing working code - Need to produce code other people can understand • Mid-term Exam: 30% • Final Exam: 30% 7 / 33

  8. Style • Must turn in a design document along with code - We supply you with templates for each project’s design doc • We will manually inspect code for correctness - E.g., must actually implement the design - Must handle corner cases (e.g., handle malloc failure) • Will deduct points for error-prone code w/o errors - Don’t use global variables if automatic ones suffice - Don’t use deceptive names for variables • Code must be easy to read - Indent code, keep lines and (when possible) functions short - Use a uniform coding style (try to match existing code) - Put comments on structure members, globals, functions - Don’t leave in reams of commented-out garbage code 8 / 33

  9. Assignment requirements • Do not look at other people’s solutions to projects - We reserve the right to run MOSS on present and past submissions - Do not publish your own solutions on the Web - That means using (public) github can get you in big trouble - Do not copy homework solutions from sources on the Web (e.g., Stackoverflow) • You may read but not copy other OSes - E.g., Linux, OpenBSD/FreeBSD, etc. • Cite any code that inspired your code - As long as you cite what you used, it’s not cheating - In worst case, we deduct points if it undermines the assignment 9 / 33

  10. Outline Administrivia 1 2 Substance 10 / 33

  11. What is an operating system? • Layer between applications and hardware emacs gcc firefox OS Hardware • Makes hardware useful to the programmer • [Usually] Provides abstractions for applications - Manages and hides details of hardware - Accesses hardware through low/level interfaces unavailable to applications • [Ofen] Provides protection - Prevents one process/user from clobbering another 11 / 33

  12. Why study operating systems? • Operating systems are a mature field - Most people use a handful of mature OSes - Hard to get people to switch operating systems - Hard to have impact with a new OS • High-performance servers are an OS issue - Face many of the same issues as OSes • Resource consumption is an OS issue - Battery life, radio spectrum, etc. • Security is an OS issue - Hard to achieve security without a solid foundation • New “smart” devices need new OSes • Web browsers increasingly face OS issues 12 / 33

  13. Primitive Operating Systems • Just a library of standard services [no protection] App OS Hardware - Standard interface above hardware-specific drivers, etc. • Simplifying assumptions - System runs one program at a time - No bad users or programs (ofen bad assumption) • Problem: Poor utilization - ...of hardware (e.g., CPU idle while waiting for disk) - ...of human user (must wait for each program to finish) 13 / 33

  14. Multitasking emacs firefox OS Hardware • Idea: More than one process can be running at once - When one process blocks (waiting for disk, network, user input, etc.) run another process • Problem: What can ill-behaved process do? 14 / 33

  15. Multitasking emacs firefox OS Hardware • Idea: More than one process can be running at once - When one process blocks (waiting for disk, network, user input, etc.) run another process • Problem: What can ill-behaved process do? - Go into infinite loop and never relinquish CPU - Scribble over other processes’ memory to make them fail • OS provides mechanisms to address these problems - Preemption – take CPU away from looping process - Memory protection – protect process’s memory from one another 14 / 33

  16. Multi-user OSes emacs firefox OS Hardware • Many OSes use protection to serve distrustful users/apps • Idea: With N users, system not N times slower - Users’ demands for CPU, memory, etc. are bursty - Win by giving resources to users who actually need them • What can go wrong? 15 / 33

  17. Multi-user OSes emacs firefox OS Hardware • Many OSes use protection to serve distrustful users/apps • Idea: With N users, system not N times slower - Users’ demands for CPU, memory, etc. are bursty - Win by giving resources to users who actually need them • What can go wrong? - Users are gluttons, use too much CPU, etc. (need policies) - Total memory usage greater than in machine (must virtualize) - Super-linear slowdown with increasing demand (thrashing) 15 / 33

  18. Protection • Mechanisms that isolate bad programs and people • Pre-emption: - Give application a resource, take it away if needed elsewhere • Interposition/mediation: - Place OS between application and “stuff” - Track all pieces that application allowed to use (e.g., in table) - On every access, look in table to check that access legal • Privileged & unprivileged modes in CPUs: - Applications unprivileged (unprivileged user mode) - OS privileged (privileged supervisor/ kernel mode) - Protection operations can only be done in privileged mode 16 / 33

  19. Typical OS structure P1 P2 P3 P4 user kernel VM file schedulerIPC system sockets TCP/IP device device device driver driver driver network console disk • Most sofware runs as user-level processes (P[1-4]) • OS kernel runs in privileged mode (shaded) - Creates/deletes processes - Provides access to hardware 17 / 33

  20. System calls • Applications can invoke kernel through system calls - Special instruction transfers control to kernel - ...which dispatches to one of few hundred syscall handlers 18 / 33

  21. System calls (continued) • Goal: Do things application can’t do in unprivileged mode - Like a library call, but into more privileged kernel code • Kernel supplies well-defined system call interface - Applications set up syscall arguments and trap to kernel - Kernel performs operation and returns result • Higher-level functions built on syscall interface - printf, scanf, fgets, etc. all user-level code • Example: POSIX/UNIX interface - open, close, read, write, ... 19 / 33

  22. System call example • Standard library implemented in terms of syscalls - printf – in libc, has same privileges as application - calls write – in kernel, which can send bits out serial port 20 / 33

  23. UNIX file system calls • Applications “open” files (or devices) by name - I/O happens through open files • int open(char *path, int flags, /*int mode*/...); - flags : O_RDONLY , O_WRONLY , O_RDWR - O_CREAT : create the file if non-existent - O_EXCL : (w. O_CREAT ) create if file exists already - O_TRUNC : Truncate the file - O_APPEND : Start writing from end of file - mode : final argument with O_CREAT • Returns file descriptor—used for all I/O to file 21 / 33

  24. Error returns • What if open fails? Returns -1 (invalid fd) • Most system calls return -1 on failure - Specific kind of error in global int errno • #include <sys/errno.h> for possible values - 2 = ENOENT “No such file or directory” - 13 = EACCES “Permission Denied” • perror function prints human-readable message - perror ("initfile"); → “ initfile: No such file or directory ” 22 / 33

  25. Operations on file descriptors • int read (int fd, void *buf, int nbytes); - Returns number of bytes read - Returns 0 bytes at end of file, or -1 on error • int write (int fd, const void *buf, int nbytes); - Returns number of bytes written, -1 on error • off_t lseek (int fd, off_t pos, int whence); - whence : 0 – start, 1 – current, 2 – end ⊲ Returns previous file offset, or -1 on error • int close (int fd); 23 / 33

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend