Last updated 2010/04/03 16:27:50
Update history:
2010/04/03: |
changed milestone document due date |
2010/02/28: |
initial version |
| Name: | Warren R. Carithers |
| Office: | 3617 Golisano (70-3617) |
| Phone: | (585) 475-5393 |
| Email: | wrc AT cs.rit.edu |
The goal of Systems Programming II is to provide students with practical experience in the design, implementation, and maintenance of operating systems, in a real hardware environment, in order to further their understanding of the impact of computer architecture and organization on the operating system development process.
The intended outcomes of this course are that students will be able to do the following:
The prerequisites for 4003-506 are:
Unless you have successfully completed these courses (or their equivalents), you will not be prepared to do the work required in this course. As your abilities will impact not only your own grade but also the grades of others in the class, if you have not passed the prerequisite courses, you will be summarily dropped from this course unless you can convince me that you have equivalent experience.
Your work in this course will be done on the computers in the Distributed Systems Lab (70-3610). These are Intel-based systems running Solaris® 10, so the environment should be similar to what you have used in the main CS labs.
The DSL has no lab assistant; you get in and out by using your RIT ID card. To gain access, you must have your ID validated in the CS office (70-3005). Please don't do this for a few days; the CS office is very busy at the beginning of the quarter, and you will not need to use the lab immediately.
For security reasons, the DSL is behind a firewall; there is no
interactive access to the lab machines from outside the lab itself, so
using these machines is less convenient than using the other CS
machines. The only access to the DSL from outside the lab
itself is ftp access from the main CS lab machines to the DSL server
itself; from any main-net CS machine, you can use the command
``ftp dsl'' to move files between your
accounts on the two networks.
This is a project course in which we will spend the first few weeks designing, implementing, and debugging a simple operating system. As we have limited time for this portion of the course, it is essential that you be ready to work during class. This means that you should be intimately familiar with what has been designed so far and should be thinking about where we should go next at each class period.
After the baseline system has been designed and initial debugging has been done, you will be required to work in teams of three or four people on additions to the baseline system. Each programming team is required to do several projects. Each team member will select a project to be added to the system; these projects may be chosen from a wide range of possibilities, but all must be approved by me. In the past, projects have included alternate system clocks, ``real'' virtual memory, device drivers (video, ethernet, floppy disk, filesystem, etc.), windowing systems, IPC, and ``kernelizing'' the baseline (among others). Note that text editors, shells, etc., although useful software, are not acceptable as projects in this course.
You should immediately begin thinking about the kinds of things that interested you in your Operating Systems course and how they might be translated into projects for this course.
In general, you will determine your own teams for this course. Teams normally consist of three or four students; depending on the composition of the class, I may allow a larger or smaller team.
Important note: Course enrollment may not allow full freedom in team selection. To ensure that each team has a ``critical mass'' of people, or to deal with problems that may arise during the quarter, I may find it necessary to overrule individual team preferences and reassign people to other teams. I prefer not to do this at all, but I will do so if it becomes necessary.
Each team will elect a team leader who will have the responsibility of coordinating the work done by the members of the team. Team leaders will meet with me as needed to discuss team progress and problems with team dynamics. The purpose of this is to attempt to identify and act on potential problems within the teams at an early date. The team leader's grade will, to some extent, be determined by his/her performance both as team leader and as a member of the team.
The first task of the team leader is to send me, via email, the names of all members of the team. This should be completed by the first class period of week three, 03/23 .
Be careful when choosing your teammates; you will be working closely with these people for many weeks, and you must be able to work together! Your grade in this course depends not on your individual effort, but rather on the success or failure of your team's effort as a cohesive unit. Pick someone you can comfortably work with; that may or may not include the most hot-shot programmers in the class. (Historically, many teams with very intelligent, capable people on them have done poorly in this course because the people on the team couldn't get along as a working group, and couldn't produce an integrated, working system.)
Everything is based ultimately on your final project. The list of major events for this quarter, and the dependence of your final grade on those events, is as follows (note that some dates are not yet firm):
| Week | Date(s) | Weight | Event(s) |
|---|---|---|---|
| 1 | 03/09, 03/11 | - |
Baseline Development Team selection due by 03/23 |
| 2 | 03/16, 03/18 | ||
| 3 | 03/23, 03/25 | ||
| 4 | 03/30, 04/01 | - | Debugging |
| 5 | 04/06, 04/08 | 5% | Project & Milestone Definition due by 04/08 |
| 6 | 04/13, 04/15 | 10% | Midpoint Review & Demonstration on 04/15 † |
| 7 | 04/20, 04/22 | - | Independent Work |
| 8 | 04/27, 04/29 | ||
| 9 | 05/04, 05/06 | ||
| 10 | 05/11, 05/13 | 10% | Project Presentations † |
| Finals | 05/17 - 05/21 | 15% | Project Source Code & Documentation |
| 60% | Final Project Demonstration † |
† Attendance is mandatory for these events:
| Event | Who must attend | ||
|---|---|---|---|
| Midpoint demonstration | All members of the team | ||
| Project presentations | Everyone | ||
| Final project demonstration | All members of the team |
Plan ahead to ensure that you are present for all presentation days and when your team is scheduled to demonstrate its project (both midpoint and final demonstrations). No excuses - this includes job interviews!
This is a description of the projects your team plans to implement, and estimated target dates for the design, coding, and testing of these projects. This document will be used during the midpoint review to evaluate your team's progress relative to its projects; although this item carries minimal weight in your team's final grade, unless it is turned in on time, your team will not be reviewed at the midpoint.
To submit the team's milestone definition, the team leader should send the document (in plain text or PDF only) to me, via email, no later than 04/08 .
At approximately the middle of the quarter, each team will give a short (approximately 10 minute) demonstration of their operating system. These demos will be given during a class period, and are intended to ensure that each team is making progress. Evaluation will be based on evidence of progress rather than the amount of progress made. This quarter, midpoint demonstrations will be done on 04/15 .
As part of the midpoint review, we will hold a discussion (if warranted) to help identify and correct any team problems that may have arisen or which may be affecting the performance of the team.
At the end of the course, each team is required to give an in-class presentation of the team's project design and results. These presentations will occur during week 10 (on 05/13 and, if necessary, on 05/11 ), and should contain the following:
The primary purpose behind the presentation is to share the information you have gained through hard experience with others in the class. Much of this information doesn't necessarily show in the final product; sharing this with others helps them to avoid the same problems.
Your presentation should be professional and technically competent, and should be the type you might give on the job in industry to technically competent people who are not familiar with your project. Each team member is expected to speak on the part(s) that he or she worked most closely on.
You may, if you wish, choose to use some type of presentation software or to use transparencies to help in your talk. I strongly recommend using one or the other to present data structures, relationships between processes, system architectural details, and other aspects that are time consuming to write or draw on the board. I will be happy to create overheads for you if you give me the originals to duplicate at least one day before the presentation.
Presentation evaluations will be based on a number of things:
The final project demonstration will occur during finals week. Each team will select a one-hour time slot (from a set of available times determined by the instructor's schedule during finals week), during which the team, as a whole, will demonstrate their operating system. The purpose of the demonstration is to show what works (and what doesn't) of the projects you planned to implement. During the demonstration, your team will have exclusive access to the DSL; you may use any or all systems in the lab without having to work around other teams.
You should plan a structured demonstration that clearly shows the operation of the various parts of your system. The ultimate goal of this course is to produce an operating system which contains all individual team member projects, fully integrated into a single, bootable system. Thus, an ``ideal'' demonstration is one in which all projects can be fully demonstrated from a single bootable copy of the OS. Separate demonstrations of each project can be shown, but you should expect that for the team to receive full credit all projects must be fully integrated into your operating system.
Project documentation and all source code are due at the time of the final demonstration (except as noted, below). Each team must turn in the following materials:
man in section 7 of the
UNIX
manual for details) if you wish, or may develop your own format;
however, each must include information similar to that found in standard
UNIX manual pages.
Documentation may be in plain text (preferred), HTML, or PDF form; please do not submit word processor source files. All documentation and source code should be submitted together from the account which has your source repository (RCS, SCCS, or CVS). The simplest approach is to include the documentation as a subdirectory of your source repository, and to submit the entire repository as a single bundle.
Finally, each team member is required to submit a peer evaluation of each teammate and a self evaluation. These evaluations will be used to determine each member's contribution to the total effort and whether or not variants of the group's grade should be assigned to some (or all) team members. (It should be noted that many different collections of grades have been assigned to team members; some teams earn all the same grade, while there have been teams where half the members receive an `A' and half receive an `F' for the course. By and large, however, variations tend to be within ± one letter grade.)
Because of their personal and confidential nature, team members may turn them in separately from the rest of the documentation and source code, but no later than one day after their team's final demonstration.
Academic dishonesty will be dealt with in accordance with DCS and RIT policies.
RIT's
Honor Code
(section 1 of the
RIT Students Rights and Responsibilities handbook).
A general statement that sets standards of behavior for all members of
the RIT community.
RIT's
Academic Honesty Policy
(section 18 of the
RIT Students Rights and Responsibilities handbook).
Defines the basic forms of academic dishonesty (cheating, duplicate
submission, and plagiarism) and explains the official RIT policy
regarding academic dishonesty.
The
DCS Policy on Academic Integrity.
Explains the official Department of Computer Science policy regarding
incidents of academic dishonesty.
Systems Programming II does not have the types of assignments found in most courses (such as exams, homework sets, labs, and traditional programming projects); thus, expectations of student conduct are also somewhat different.
By its nature, the work students do in this course builds upon the work done by others. Communication between students is expected and encouraged, as the overall goal is the understanding of the concepts and techniques related to operating system design and implementation. It is entirely reasonable to expect students to discuss design and implementation details with members of their own team, as well as with members of other teams. Furthermore, it is entirely reasonable for students to examine source code from existing operating system implementations to aid in their understanding of methods and concepts, and to provide inspiration for their own development efforts.
With this in mind, it is expected that work submitted for credit is the product of the student(s) submitting it. Influences from other sources (discussions with other people, concepts obtained from available source code, etc.) must be clearly and prominently identified. Unless absolutely necessary, code should not be copied directly from other sources; if this is necessary, the included code must be clearly identified and properly attributed.
Any questions or concerns regarding this policy should be referred to the course instructor; to rephrase a classic aphorism, "It is better to ask permission than to beg forgiveness".
Normally, the number, type, and relative weights of assignments will not change from those specified in the syllabus and other course documents. However, I reserve the right to make changes to these or any other facet of the course, at my discretion, based upon the events of the quarter; if such a change must be made, you will be notified in class, via electronic mail, and on my web page for the course.