CSC311 Operating Systems
4th term 2012
this page is a work in progress and subject to change
Bill Tucker (firstname.lastname@example.org) assisted by Carlos Rey-Moreno (email@example.com)
This course has several purposes:
· The overall goal is to provide an introduction to core Operating Systems (OS) concepts: history and system calls, processes and scheduling, input/output (I/O), memory management and file systems.
· Corollary goals include learning to program in C, thoroughly document code and make use of development tools such as revision control and performance profiling.
· By the end of the course, you will be knowledgeable of fundamental OS theoretical concepts and be able to code and document practical applications of the theory in C.
NB: This courses covers the theoretical sections of each chapter in the textbook. The implementation sections will be addressed in the Honours OS course.
This course meets four times a week for 7 weeks. There are three lecture periods per week and a practical during which I'll lead discussion for about an hour. Thus, in practise, there are 4 contact hours per week. For every hour of contact time, you should spend about 2.5 hours of your own time studying and/or working on assignments. Overall, the schedule requires that you spend a total of 100 hours on this course. This is 14 hours per week. Think carefully how to plan your time, with respect to the course demands and the other courses that you are taking.
You are meant to complete an assignment before its due date. We will drive your team's programming assignment (see below) during period 3 on Friday. We will discuss that assignment that same day at 2pm, and then introduce and start working on the next assignment for the rest of the prac. Note that the NetLab will be closed on Friday periods 1 & 2 because you are expected to attend lectures for other courses/sections. We may also opt to suspend login access during that time, so finish coding and documenting
Tuesday, period 3, SC254 (lecture)
Thursday, period 1, SC254 (lecture)
Friday, period 3, SunLab (practicals due)
Friday, period 5, WinLab (lecture) NB: periods 6-7 will be for Networking
to be determined
Virtual machines are accessible anytime!
purpose: syllabus, assign teams, intro to MINIX and operating systems
textbook: Chapter 1: OS concepts and history
slides: this syllabus, Chapter 1,
purpose: System calls and processes
assignment 1: due Friday, period 3
textbook: Chapter 1: system calls, Section 2.1: processes and threads
slides: Chapter 2
Week 3: Interprocess Communication (IPC)
assignment 2: due Friday, period 3
Section 2.2: interprocess communication
slides: still Chapter 2
purpose: Classical IPC problems and scheduling
assignment 3: due Friday, period 3
textbook: Section 2.3 dining philosophers, Section 2.4 scheduling
slides: still Chapter 2
purpose: Input/Output (I/O),
assignment 4: due Friday, period 3
textbook: Sections 3.1-3.3
slides: Chapter 3
purpose: Memory management
assignment 5: due Friday, period 3
textbook: Sections 4.1-4.6
slides: Chapter 4
purpose: File systems
assignment 6: due Friday, period 3
textbook: Sections 5.1-5.5
slides: Chapter 5
NB: Programming assignments must be done on MINIX. These are accessible from anywhere on campus as virtual machines. No other programming platform, including both Solaris and Linux, will be accepted. See below for instructions on how to access your team's MINIX virtual machine.
Pop Quiz: 50%
Marking is entirely based on continuous assessment via pop quizzes and assignments. We will drop the lowest scoring pop quiz and assignment.
NB: There is no final exam!
A pop quiz can be handed out at any contact hour and will be unannounced and always given precisely at the beginning of that contact period.
All assignments are done by programming teams of 3 people. You will choose team membership yourselves, so think carefully about who you want to work with, what their schedules and work habits are, etc.
NB: assignment hardcopy is due at the beginning of period 3 on Friday when we drive your solution in the SunLab. If your code does not work, we don't mark anything. If you don't hand in hardcopy, you don't get marks.
NB: If you copy code or documentation from any other group, past, present or future, it is considered cheating.
NB: You are expected to learn how to use source code control, specifically SVN, on your own, and include the SVN log in all source code submitted (see below).
NB: Two conditions hold in order to receive points for an assignment:
1) the application must pass the driver and/or inspection
2) fully documented hardcopy must be turned in at the beginning of period 3 on the due date.
NB: late arrivals and/or non-working solutions simply receive 0 points. This is not negotiable!
The mark for each assignment is shared by all team members. The marking scheme for a programming assignment is as follows:
10 pts. - Code design and efficiency
10 pts. - Code demonstrates use of source code control, e.g. contains SVN log
20 pts. - Code readability, naming conventions, format and indentation
10 pts. - Module level documentation
30 pts. - Function level documentation
20 pts. - Code level (in-line) documentation and comments
Total 100 pts.
Here's an example of how we expect code to be formatted and documented.
You can access the MINIX VM from anywhere on campus, e.g. the SunLab or your laptop connected via Free4All: just login to the virtual machine. We demo code in the SunLab each Friday during period 3. From just about any machine on campus, you'll have to VNC or ssh to your MINIX VM. There are more details at the bottom of this document.
Paper and presentation assignment
The paper will be marked as follows:
10 pts. – technical content
10 pts. – format and presentation
10 pts. – grammar and spelling
10 pts. – organization and flow
10 pts. – title, abstract & bibliography
The presentation will be marked as follows:
10 pts. – delivery
10 pts. – content
10 pts. – visuals
10 pts. – timing
10 pts. – Q&A
Pop quiz marks, on the other hand, are completely individual. Pop quizzes are unannounced 5 or 10 minute tests at the beginning of any class/contact-time (including pracs) that continually assess your knowledge and also keep you prompt. A pop quiz can address any of: what we covered already, what is supposed to be covered the day of the class and/or anything to do with assignments (finished or current).
Be sure to read the appropriate chapter (sections) before coming to class. You cannot make up a pop quiz, no matter what the excuse. To encourage you to obtain the book, all pop quizzes are open book. Statistical evidence definitively shows that people that obtain and read the book score higher marks! A book may not be shared between people during the pop quiz. One person, one book!
NB: if you copy answers from the book or anywhere else, it will be considered cheating. You must use your own words.
The lectures should not be a one-way street from me to you. Yes, I will conduct lectures, but you must also participate by asking and answering questions. Class participation, however, is not marked. The class is just too big to do that fairly.
NB: There is no final exam. YES THAT'S RIGHT! THERE IS NO FINAL EXAM!
Cheating of any kind will not be tolerated - be it copying or plagiarism on any aspect of programming assignments and/or pop quizzes. Any student involved in cheating will be strictly dealt with according to UWC disciplinary procedures. Since the assignments are group work, the groups work together in the same lab, it is natural and encouraged that people discuss the assignments and course material. That is fine. Just don't copy code from one group to another. Copied code is plagiarism and it is VERY EASY to detect! In other words, copying code around from one group to another is considered cheating, even if that group is no longer around. We will issue a form for you to sign to acknowledge that you understand what we mean by cheating, and a short paragraph to include in the source code control log for each programming assignment.
Tanenbaum, A., & Woodhull, A. S. (2006). Operating Systems: Design and Implementation (3rd ed.). Upper Saddle River, New Jersey, USA: Pearson/Prentice Hall.
NB: Due to the generosity of the local arm of Pearson publishing, we have a number of books available on a lease basis. You pay a deposit of R500 on the book to Rene in the CS office. If you return it to us in good condition, you get your R500 back. Otherwise, you keep the book, and we keep the money to replace the copy you defaced or destroyed.
NB: older versions of this book are just as useful. Get your hands on what you can.
B. Kernighan and D. Ritchie (1987). The C Programming Language. 2nd Edition, Prentice Hall, New Jersey, USA, ISBN: 0-13-110362-8.
Infusion objectives extend beyond the technical content of the course. At UWC Computer Science department, we are also interested in growing you as a person with respect to professional, ethical and social skills. This course situates technical aspects of course content and structure within the context of the workplace we are preparing you to work in upon graduation. This course does this in the following ways:
Problem Solving: The course challenges you with a series of increasingly difficult assignment and pop quiz problems to develop your problem solving skills incrementally over the course of the term. In doing so, we intend that you learn and apply advanced problem solving techniques to more and more difficult problems.
Programming Competency: We expect you to code robust and efficient solutions using standard software development tools. We expect you to learn to acquire and master the MINIX programming environment including the C language, the compiler, editor, system libraries, man pages, makefile utility, source code control, profiling and other programming tools. Furthermore, we expect you to learn these tools mostly on your own using offline and online sources.
Team Work: All assignments are solved by a programming team. Teams are randomly assigned at first, and then we allow you to choose team membership. You can choose to work with friends or with people that have a healthy learning attitude – hopefully a combination of both. This is what it will be like when you graduate and work for a company. Managers tend to promote people that find innovative ways to achieve results while overcoming interpersonal problems. Thus both random and self-assigned team membership helps you develop valuable social and technical skills as you endeavour how to make teamwork productive to submit a successful assignment.
Leadership: Even though the teams will be small, someone inevitably assumes a leadership role by splitting up and assigning responsibilities within a team. It would be useful for all team members to assume that role at least once in order to learn how to do so. You have seven golden opportunities! One for each assignment!
Ethics & Professionalism: The 'real' world is very different from the university setting, especially with respect to two things:
1) that a solution work as perfectly as possible. Who cares at uni? All you have to do is 'pass'. In the 'real' world, people do not purchase software that does not work and you could lose your job if your code does not work.
2) external and internal documentation of the code must convey how the solution was achieved and what its limitations are. This is as true in the open source world as in proprietary code. You will find that documentation is perhaps the most important part of being a software engineer.
The marks for an assignment are purposefully tied to these two objectives. First, an assignment is only marked if it works properly. Second, the marks are mostly based on documentation of the code.
Responsibility: The structure of the course is designed to make you cognizant of your responsibilities for time management. You will have to manage your time effectively due to the challenging and constant workload of programming tasks and course preparation to do well on the pop quizzes; all within the context of the rest of your studies. Watch yourself and adapt to increase productivity! We encourage you to make a contribution to the group task by examining you individually on group efforts with pop quizzes, and also making you responsible for high marks within the group. We also challenge you to take responsibility for your own marks by encouraging you to get the book on your own. The book may not be shared during a pop quiz!
Software Development: We expect you to employ the techniques acquired in the software engineering course to the assignments in this class. From a profession point of view, this means various techniques to go through the Software Development Life Cycle and authoring clear and explanatory documentation of your solution's design.
How to access the MINIX virtual machines (note this may be slightly out of date)
First, your team chooses a SunRay in the NetLab. Your team will use that machine for the entire term. Write your team number and your names on a small piece of paper and tape it to the monitor so we know which machine belongs to which team.
A MINIX kernel has been pre-installed on a virtual machine for each team (see this diagram). There is also a MINIX VM server that has the drivers. In a nutshell, a Sun Ray server in the SunLab runs the display and basic OS (Solaris) of the Sun Rays, a VMWare server runs the MINIX VMs and another server in the BANG lab hosts the Subversion server for source code versioning. You can access the MINIX VM from the Sun Ray with the VNC client. Consider that the console. Once you know the IP address of your team's MINIX VM, you can also ssh into it from a standard xterm.
Figure 1 Network diagram
minix01 - minix17 are VMs for students, username/password is root/csc311 :: you will want to change this, and also add user accounts for yourselves (man adduser), and possibly a group account. In general, it is not wise to do all the coding as root. Rather create and use another user.
minix-ftp is the public FTP server, ftp username/password is csc311/csc311 :: use this to copy the driver, our executable solution and the sample testfile(s) to your VM.
name IP address VNC access note
name IP address VNC access note
minix01 172.16.39.201 172.16.38.44:5901 students
minix02 172.16.39.202 172.16.38.44:5902 students
minix03 172.16.39.203 172.16.38.44:5903 students
minix04 172.16.39.204 172.16.38.44:5904 students
minix05 172.16.39.205 172.16.38.44:5905 students
minix06 172.16.39.206 172.16.38.44:5906 students
minix07 172.16.39.207 172.16.38.44:5907 students
minix08 172.16.39.208 172.16.38.44:5908 students
minix09 172.16.39.209 172.16.38.44:5909 students
minix10 172.16.39.210 172.16.38.44:5910 students
minix11 172.16.39.211 172.16.38.44:5911 students
minix12 172.16.39.212 172.16.38.44:5912 students
minix13 172.16.39.213 172.16.38.44:5913 students
minix14 172.16.39.214 172.16.38.44:5914 students
minix15 172.16.39.215 172.16.38.44:5915 students
minix16 172.16.39.216 172.16.38.44:5916 students
minix17 172.16.39.217 172.16.38.44:5917 students
minix-ftp 172.16.39.221 172.16.38.44:5918 students public FTP server
Note that the SunRay server and the Subversion servers have RAID, and are therefore automatically backed up. The VMWare server is not backed up. We strongly recommend you find a way to back up your source code even though when you use Subversion, it is automatically backed up for you with RAID 1 mirroring.
NB: the best way to shutdown MINIX is to use the shutdown command. Then everything comes down cleanly, and the next reboot is quick.