Last updated 2013/03/01 17:48:43
Update history:
2013/03/01: |
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:
implement low-level system software including device drivers (e.g., terminal, disk, and network devices), kernel functions, scheduling algorithms, context switching, interrupt handling, memory management, and/or filesystems;
enhance an existing complex software system;
integrate disparate components of a complex system;
propose a project and develop and implementation timeline for it; and
work as members of a team towards a team solution.
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
Ubuntu® 12.04,
and the environment has been set up to be
very similar to what's installed on the systems in the main CS labs.
The lab has a laser printer called dsl_lw1 (also known as
watson, in keeping with the system naming scheme used in the
lab); all the DSL systems have been configured to use it as their default
printer.
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 entered into the security system; to do this, see Mark Stamer (70-3441), the CS hardware technician. Please don't do this for a few days; things tend to be very hectic 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 DSL server runs a web proxy server, so you do have access to the web
from inside the lab, but only HTTP and HTTPS requests are forwarded.
No other access from inside the lab to the outside world is available.
All the DSL systems are configured to use the proxy server by default,
so accessing the web should be completely tranparent regardless
of which browser (Firefox, Chromium, lynx, links, and links2 are currently
installed) you use; however, some (notably Firefox) sometimes ignore the
system-wide settings.
If you find this to be the case, you'll need to manually configure your
browser to use port 8888 on a proxy server named mycroft.
The ony access to the DSL from outside the lab
itself is ftp access to the DSL server; from the outside world,
the DSL server is named dsl, and
you can connect to it using an ftp command (e.g.,
ftp dsl
within a shell window) or an ftp application
to move files to and from your DSL account.
The DSL machines have USB jacks which will accept flash drives.
To use a flash drive, simply insert it into one of the computer's
USB jacks; Ubuntu should examine it and, assuming it has a
file system that Ubuntu recognizes, automatically mount it into
the file system.
The mounted drive will be found in
/media/name (where name
is determined by the name used when the flash drive was formatted).
If there is no recognizable file system on the drive, it will not be
automatically mounted.
Unmount the drive before unplugging it from the machine.
To do this, you can either right-click on the desktop icon representing
the drive and select eject, or you can use the
df command in a shell window to determine the actual
device path (e.g., /dev/sdb1) and then run the command
umount /dev/sdb1;
when you see the next command prompt, it is safe to remove the
flash drive.
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, PATA/SATA devices, etc.), file systems, windowing systems, IPC, "kernelizing" the baseline, and many others. (However, text editors, shells, etc., although useful software, are "application-level" programs, and as such 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, 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. 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/19 .
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 people 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.)
Finally, although it is typically the case that teams are able to work together well, there are occasional bumps in the road (often the result of "ego clash" between team members). Should issues with team dynamics impede the team's ability to make progress, I will step in if needed to act as a mediator to help deal with the situation. However, this does require that I be kept "in the loop" regarding such issues; while this information often comes from the team leader, team members should feel free to let me know when problems arise. I'll meet with the team (or with team members) as needed to discuss the situation and help the team reach a solution to the problem.
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 (be aware that some dates - particularly, those in the middle of the quarter - may change):
| Week | Date(s) | Weight | Event(s) |
|---|---|---|---|
| 1 | 03/05, 03/07 | - |
Baseline Development and Debugging Team selection due by 03/19 |
| 2 | 03/12, 03/14 | ||
| 3 | 03/19, 03/21 | ||
| 4 | 03/26, 03/28 | ||
| 5 | 04/02, 04/04 | 5% | Project & Milestone Definition due by 04/02 |
| 6 | 04/09, 04/11 | 10% | Midpoint Review on 04/11 † |
| 7 | 04/16, 04/18 | - | Independent Work |
| 8 | 04/23, 04/25 | ||
| 9 | 04/30, 05/02 | ||
| 10 | 05/07, 05/09 | 15% | Team Presentations † |
| Finals | 05/13 - 05/17 | 20% | Project Source Code & Documentation |
| 50% | Final Project Demonstration † |
† Attendance is mandatory for these events:
| Event | Who must attend | ||
|---|---|---|---|
| Midpoint review | All members of the team | ||
| Team 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 to me via email as plain text (preferred) or PDF (no binary word processor files, please!) no later than 04/02 .
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/11 .
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/09 and, if necessary, on 05/07 ), 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 to help in your talk. I strongly recommend this when you are presenting data structures, relationships between processes, system architectural details, and other aspects that are time consuming to write or draw on the board. You may bring your own laptop to present from, or you may present using one of the DSL systems using Impress (the presentation component of LibreOffice, installed on the DSL systems) or Google Docs.
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.
Within your source code, I expect that some type of programming style standard be followed. I do not care what specific style you used; it's more important that your code be neat, clear, and (above all) consistent. Here are the major things I'm looking for:
Although your code will not be written in C++, you may find the example style standard for C++ from CS4 (found online in HTML, PDF, and PostScript forms) to be helpful.
Documentation may be in plain text (preferred), HTML, or PDF form; please do not submit word processor source files. The DSL systems have several source code control systems installed (RCS, SCCS, CVS, Subversion, git), and you are free to use whichever you prefer. All documentation and source code should be submitted together from the account which has your source repository. 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. If you use a revision control system that maintains its repository in binary, be sure to extract the full set of files into a directory or directory hierarchy and submit them along with the repository.
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".
RIT is committed to providing reasonable accommodations to students with
disabilities.
If you would like to request accommodations such as special
seating or testing modifications due to a disability, please contact the
Disability Services Office.
It is located in the Student Alumni Union, Room
1150; the Web site is
www.rit.edu/dso.
After you receive
accommodation approval, it is imperative that you see me during office
hours so
that we can work out whatever arrangement is necessary.
Disclaimer: 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.
Documentation and Programming Style: I expect students to follow some reasonable form of programming style. I don't mandate a specific style; for the most part, it's more important that your code be neat, clear, and (above all) consistent. Here are the major things I'm looking for:
An example style standard for C++ from CS4 can be found online in HTML, PDF, and PostScript form.
Warning: This course requires a significant amount of out-of-class work. I strongly suggest that you very carefully consider whether or not you should take any other courses that have similar workloads along with it.
Withdrawing:
During the add/drop period (the first seven calendar days of the quarter),
you may drop this course and it will disappear from your transcript.
After that time, you can only withdraw from the course; the course will
appear on your transcript with a grade of W.
Deadline to add/drop: Sunday, March 10, 2013
Deadline to withdraw: Friday, April 26, 2013
Grading: This is not a lower-division course. Think about what this should mean to you. You will be expected to incorporate all you have learned so far into this course; i.e., you will lose points for not following assignment instructions, for submitting code that is sloppy, undocumented or unstructured, etc.
Assignment of final grades:
|
I use a traditional 90/80/70/60 percentage-based grading scale in this class.
I reserve the right to alter these division points as I see fit at the end of the quarter if I believe it to be necessary, based on my overall evaluation of individual or class performance and effort. |
|