Grading is 60% labs, 40% final, 10% class participation.
Lab grading criteria will be set by TAs. There will be four full credit labs.
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.
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 a machine simulator for most of the lab work. It has the advantage of making it significantly easier to debug your OS components but it is not portable. Thus you will need to use csil.cs.ucsb.edu all work.
You should also be fairly proficient with C and Linux. The course schedule assumes that you have more than a passing familiarity with the C programming language, and that you are familiar with the standard Linux system calls. These lecture notes show examples of the C and Linux programming facilities that will be necessary to complete the programming assignments. Your instructor will give a C tutorial using them in the first Disscussion Section (please see the discussion and section page for details) to help refresh your skills. If this still 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-neophyte 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 will 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 prerequisites, 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 will need to form a team of two to complete the labs.
In this class you will need to work on the labs as a team of two. There are advantages and disadvantages to this 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, 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 instructor does realize that forming a team can be onerous. This requirement is borne of significant experience with students in the past attempting to complete the OS labs invididually or in larger teams.
With all of this said, if you absolutely feel like you cannot form a team, you can attempt to convince the instructor that your preparation for this class is such that you have a good chance of success working alone.
The point totals for the labs are, roughly,
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 lab1. Each lab after lab1 depends on the correct function of all of the previous labs up to and including lab1.
For reasons that will become clear as the lab development progresses, your chances of success will be maximized if you use the TAs to help with your lab questions with greater frequency than your instructor. I am more than happy to try and help with your labs either on Canvas or during office hours but previous experience with this course material indicates that the TAs are more scalable debugging aid. 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 lab1 on time. The score for lab1 will be recorded as a zero, but lab2 depends on a working solution to lab1. The hapless student is now faced with the tasks of completing lab1 and developing a solution to lab2 in the time allocated for lab2 alone in order to get a score for lab2. The same is true for lab3 with respect to both lab1 and lab2. Thus, lab3 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.
Please read this paragraph again. If your coding style is to download code from the web (regardless of source) and to modify it, then you will need to adopt another style in which you write your own code from scratch in this course. The exceptions to this rule are the code fragments the instructor or the TAs make available.
Additionally, you MUST use the UCSB github installation if you plan to use a source code repository to aid in collaboration. You must make your repo private to you and your teammate. No exceptions to this requirement will be made, and a failure to comply will result in a failing grade. This Guide explains how to get an account.
Enough said.