CS170 -- Operating Systems

Rich Wolski --- Winter, 2014

General Information


Professor: Rich Wolski TA:

Class Meets Mon. and Wed. 12:30 PM - 1:45 PM in Phelps 3515

Discussion sections:

Grading is roughly 50% labs, 20% midterm, 30% final, 10% class participation.

Lab grading criteria will be set by TAs. There will be five full credit labs and, perhaps, an extra credit lab.


Lecture Notes

There will be lecture notes provided for each lecture that will available via the class web site. The point of lecture notes is to outline what I would like you to learn from each class. If I covered material from the book, the notes will specify the sections. If the material is not in the book, the notes will contain instructional reference material. It is a really good idea to come to lecture with a printed copy of the lecture notes so that you can annotate what is presented. Empirically, students who have followed this practice in this class in the perform significantly better in terms of their final grade.

All programs that I go over in class will be available on-line. The point here is that you don't have to try to copy them down in class. That is a waste of your time, which is best occupied otherwise. Code examples will all have been tested on the department's Linux machines. Some of you may have access to your own Linux machines. You can use your own machine for the class, but you (and only you) will be responsible for making all of the software work.

The course materials are evolving. Please check the web pages early and often and RELOAD each time as I will be tuning the course as we go along. Report problems with any of the the web pages to the TAs.


Labs

The labs are where you are going to learn the most in this class. They are fairly labor intensive and some of them require quite a bit of thinking. Start early. Put another way, don't leave the work until the last minute. In other words, don't procrastinate. We will be using pthreads and a MIPS simulator for most of the lab work. Neither one is particularly easy to debug. You should also be fairly proficient with C and Linux. The course schedule assumes that you can program at better than a beginning level in C, and that you are familiar with the standard Linux system calls. If this doesn't sound like you, start earlier or consider taking this course at another time. The TAs will not, unfortunately, have time to teach much C and Linux programming.

These points are important enough to our combined stress levels to be worth repeating. Operating systems, when taught as a projects course, is a labor intensive endeavor. For this course, you will need to be a better than beginner C programmer (C++ does not count and forget Java, Python, Ruby, or any of the other languages that have gained popularity of late), you will need to know how to use the Linux system calls (not just the command-line utilities), and you need a basic understanding of computer architecture. If you don't fit these characteristics, and you are concerned about your grade in the class, you should think about taking the class another time. Or, if you fit the pre-requisites, but you have a busy, labor intensive quarter on your docket -- again discretion may be the better part of valor for you. Lastly, if you find that you are someone who is most comfortable waiting until the last minute to begin a project, you need to understand that the success rate for students who share this predilection is abysmally low for this material. In this case you should either modify your habits to your discomfort or, again, think about taking this course at another time.

You may form a team of two or complete the labs individually.

In this class you may either choose to work on the labs individually or as a team of two. There are advantages and disadvantages to each approach. Working as a team allows you to divide the workload and to collaborate more closely during the learning process. It also adds time management risks since it will be necessary to coordinate your work with that of another student. Also, in the case of a team, both members will receive the same grade for each lab. That is, the lab will be graded, and those who worked on it will receive that grade.

In the "real world" operating systems are built by teams of developers, so a team approach is probably the best preparation for what a career in this field will demand.

You need to decide whether you plan to work alone or as a team by the time the first lab is due. If you turn in lab1 alone, then you will be required to work alone on the remaining labs. Conversely, if you turn in lab1 as a team, then the remaining labs will be graded for that team.

The point totals for the labs are, roughly,

with the latter labs worth the most.

An interesting feature of operating systems development is that generally, it takes place in layers, from the bottom up. That is, upper-level features depend on the correct functionality of lower level code. In this class we will experience such realism starting with lab2. Each lab after lab2 depends on the correct function of all of the previous labs up to and including lab2.

All technical questions regarding the labs should be directed to the TAs first and only to me if they are unable to resolve them. The TAs will be responsible for managing the lab projects. Your should enjoy their guidance as much as possible. Administrative issues, however, should be directed to me, exclusively, by email.

WARNING: Due to the size of the class course material, no late work will be accepted. None. I'll explain why in class, but really, if it is late, it won't be graded and it will be counted as a zero.

Please read the previous 6 paragraphs again carefully. They are important. Consider what they mean with respect to your schedule. No work will be accepted late, the later labs are worth more than the earlier labs, and you need to get to the earlier labs working to get the later labs working. We will not be distributing solutions to any of the labs during the course. Therefore, it is imperative that you correctly budget your time for this class.

To see why, consider the following scenario in which a nameless student fails to complete lab2 on time. The score for lab2 will be recorded as a zero, but lab3 depends on a working solution to lab2. The hapless student is now faced with the tasks of completing lab2 and developing a solution to lab3 in time allocated for lab3 alone in order to get a score for lab3. The same is true for lab4 with respect to both lab2 and lab3. Thus, lab6 is, for the most part, an operating system that you have developed yourself, but it will depend on your ability to develop all of the other components in the previous labs -- and to do so on time. Learning to gauge your development effort and time-to-solution is a big part of what the course has to offer in terms of professional development.

Please do not wait until the last minute to begin the labs -- any of them. I'm not kidding. Really. No matter what temptation may come your way to do otherwise, you will need to stay on top of the work required for this class in order to receive a successful grade.


Handing in Labs

Labs will always be due at 11:59:59PM on the specified night. To submit homeworks, you should go through the following steps: If you are working as a team, only one team member should submit the lab, but you should indicate the names of the team members in the submission materials.

You may talk with the TA, other students, or me about your homeworks, but do the programming on your own or with your teammate. Copying other students' or team's code is considered plagiarism. Copying code from the web is plagiarism. Copying code from a text book, a set of class notes for another class -- any copying at all is plagiarism.


Speaking of Plagiarism

You should protect the directories that your homework is in so that no one but you can read it. I have seen too many instances of copying recently, and it can be prevented if you protect your directory. If we discover copying this time, both the copier and the copyee (?) will be penalized. Be careful. Enough said.