Carnegie Mellon
SCS logo
Computer Science Department
home
syllabus
staff
schedule
lecture
projects
homeworks
 
 

15-410 Policies and Mechanisms


About This Document

This document sets forth specific policies and mechanisms for this class. You must also read the companion document on high-level Expectations.

Prerequisites

If you have not completed 15-213 with a grade of C or above, you must contact the course staff and complete a skill assessment exercise to remain registered in the class. This requirement specifically includes all graduate students, exchange students, non-degree students, and any other special students. This also includes all students who have taken Operating System classes other than 15-410.

Auditing

Please see the "Audit Grades" section of the University's Grading Policies document. Students auditing a class are required to to commit to some level of participation, and to meet that commitment in order to receive an audit grade at the end of the semester.

Getting Help

The class web site is http://www.cs.cmu.edu/~410-f08/.

You should read and participate in academic.cs.15-410.qa and are required to monitor academic.cs.15-410.announce (if your mail client can be set to alert you of new messages, that would be a good idea).

Issues particular to you or your group, and time-critical issues, can be addressed to staff-410@cs.cmu.edu. If you need to discuss a genuinely confidential issue you should contact the instructor(s) directly. But you should not send e-mail to randomly-selected staff members to ask clarification or guidance questions--if nothing else, you may choose somebody who is sick or out of town.

Please do not send us files via electronic mail. Really! If you want us to look at some of your files, you should put them into a private AFS directory, make sure we can read it, and send us the filename. If you use course-issued AFS space, this is easy, since 410 staff can automatically read that. If you use some other AFS space, you will need to do something like this:

% fs sa . de0u:410staff rl
% fs sa .. de0u:410staff l
% fs sa ../.. de0u:410staff l
Eventually you will be told "permission denied" and then you are probably done.

AFS access control lists

Be sure to store your work in a protected area. Since a new AFS directory inherits its parent's access control list, it is possible to create a directory which inadvertently is public.

AFS problems

Like any other large complicated thing, AFS can have problems. If it happens to you, please start by re-reading About your 15-410 AFS Space--please don't e-mail us a question which is already answered in that document.

Formatting

"Documents" should be submitted in a document interchange/publication format such as PDF or HTML (or, if appropriate, Unix-line-delimited 7-bit ASCII). Microsoft Word, WordPerfect, OpenOffice XML, FrameMaker editable-document format, etc., are not interchange formats. PostScript is really a printer transport language rather than a document interchange format, but it will generally suffice.

Also, if we ask you to use a particular filename for something, please do that. We probably intend to use a program to perform some action (such as printing) on all 100-odd files, and if your file doesn't have the right name maybe the right thing won't happen to it.

Hazards

Medical issues

If you experience a medical problem which disrupts your studies, please go to Student Health Services (or another medical provider) and have them emit some piece of paper describing the situation and what you are medically required to do about it. If there are privacy concerns, we will accept a firm statement of the restrictions on your activities without a description of the condition itself.

Please do not come to the course staff and tell us that you've been too sick to attend class and code for two weeks but that it hasn't "been bad enough" to merit medical attention. If nothing else, it probably has been "bad enough" for your partner.

You may prefer to disclose an ongoing medical situation to Mark Stehlik and/or Catharine Fichtner (or your home department's undergraduate chair and/or administrator). They can then take care of notifying all of your instructors.

Partner problems

Please try to avoid having partner trouble. Seriously! Share your hopes before they turn into concerns, your concerns before they become problems, and your problems before they inflate into crises.

Also, in order for the course staff to help you and your partner work through issues, or for us to provide special treatment in response to serious partner problems, you must contact us well before the relevant due date. While some problems can never be truly solved, it is likely that your career after CMU will require you to "involve management" to address issues with co-workers... if you find yourself in a situation which you can't resolve, this will provide you with an opportunity to practice interacting with management.

One special case to avoid is coming to us a day or two before a major deadline to tell us that your partner has been ill for multiple weeks. We, and thus you, have many more options if you inform us while a problem is developing, as opposed to after the fact.

Exams

Exams will be closed-book. For the final exam you will probably be permitted to bring in a single sheet of notes.

At CMU, standard operating procedure is that final exams take place after classes end, during a special period of time. Each class is assigned an exam period according to a university-wide procedure which attempts to minimize conflicts.

What this means is that the date and time of the 15-410 final exam will not be decided by the course staff, and we do not know when the university will make the decision (the schedule is posted at approximately the same time every semester, but there is some variation).

It is your responsibility to alert the course staff to any exam conflicts. If we haven't heard from you seven days after a 15-410 exam date has been published, we will expect that to mean you do not have a conflict. In any case, notify us as soon as possible.

Collaboration and Group Work

We think a lot can be learned by talking to other students, and, since we're pro-learning, this is generally ok with us. Discussing your data structures, module boundaries, and even the flow through your code is fine. Writing down snippets of code on a whiteboard is also ok (especially if you gesticulate wildly while doing so and use several colors).

However, some sorts of "collaboration", which reduce or impede learning, are not acceptable, such as:

  • "Discussing" code in sufficient detail to fully specify it (see, for example, Jonathan Baccash's BabelBuster C to English to C Translator.
  • Copying or typing in code from other people, or any OS class you might have taken before (if you can meaningfully do the latter, there is a good chance you shouldn't be taking this class for credit). You should also not be reading code produced by other people for OS classes at CMU or elsewhere, or components from "how to write your own mini-OS" kits.
  • Allowing other people to type in code for you or debug your code.
  • Allowing other people to read your code before it is turned in or before they have turned in their own code.

In the other direction:

  • You may read books about operating system internals and browse "professional" OS code (e.g., a BSD kernel, the Linux kernel, etc.).
  • It's ok to re-use basic code from lower-level classes. If you have to sort something, it's fine to consult a book or even type in code from one (giving appropriate credit, of course).

You should have a reasonable understanding of all code your group turns in, even parts you didn't write. One easy way to think about this is that exam questions which assume understanding of project components are fair game. Also, while we hope this will be a rare occurence, we we reserve the right to assign partners different grades for a project.

Homework assignments are individual. Your model should be that you can talk about the problems, but then you must erase the whiteboard or shred the napkin, retreat to your cave, and write them up yourself.

If you question the legality of any type of collaboration or consultation, please ask. If you are in a real bind, do what feels right and discuss the issue with a staffer as soon as is possible. If you discuss the issue with us before you turn in your solution or document it as part of your solution, it will not be considered to be academic dishonesty (of course, it might not qualify for full credit, either).

You should be aware that there are several sophisticated code-similarity analysis tools based on machine-learning techniques. Fooling them is possible, but probably requires enough work (and worry) that it is probably better for you to do the assignments yourself.

Academic dishonesty may result in a failing course grade, and will typically be reported to your home academic unit and/or the Dean of Students. Please don't get involved in this--it costs everybody enormous amounts of time during which nothing can be learned about operating systems.

Grades

Documentation will be a component of your course grades. The exact percentage may vary from one assignment to the next, and may be adjusted in response to class performance, but your model should probably be that documentation will be worth approximately 5% of each programming assignment.

In general we will have a "7 CMU business day" deadline on grade appeals. That is not to say that we will never engage in grading archaeology, but we believe we can obtain a greater degree of consistency inside a smaller time window.

Here is a tentative, approximate grading breakdown.

Weight Item
5%Zeroth Programming Project
5%First Programming Project
15%Second Programming Project
25%Third Programming Project
5%Fourth Programming Project
15%Midterm Exam
20%Final Exam
10%Homeworks (~3) and book report

There is an excellent chance that the weight of the kernel project will be increased somewhat, probably at the expense of the homeworks.

In addition, your weighted project average and weighted exam average must each be a passing grade in order to pass the course.

Cutoff points for grades will be set by the course staff based on an examination of the quality of the work turned in by students near the border. Likewise, individual students, especially those near a cutoff, may receive adjustments upward or downward based on factors such as quality improvement, final exam scores, dramatic differences between partners, or other circumstances relevant to the estimation of the staff of which grade best represents the student's work.

Finally, while we do our best to specify our expectations in advance, grade assignment is at the discretion of the course instructor.

Policy on Late Work

Here is a somewhat traditional OS policy on late work:
Each student may grant himself or herself an extension on any homework assignment or project deadline/checkpoint -- but only three (3) days worth of extensions are available during the course of the semester under this policy. Possible configurations include turning in three projects one day late apiece, turning in each homework assignment one day late, etc.
If a team wishes an extension under this policy, the number of days available is the minimum of the number of days that each member has available. Because this might become an issue if you switch partners, it is probably unwise to use up too many late days on the earlier assignments.

Please understand that the use of extensions may, perhaps severely, delay the grading of your assignment. This isn't intended as punishment, it is just the natural consequence of the need to have all of the staff assembled to fairly assign grades. We'll do our best to be timely, but once extensions are injected into the system, this can sometimes become difficult.

We encourage you to reserve extensions for the inevitable: minor illnesses, conferences, University trips, bad karma, &c. But you are free to use them for any reason that you'd like. Just please remember that you have only a small fixed number of extensions.

Extensions beyond the standard quota will only be granted for extremely unusual, extremely unforeseeable, and/or extremely incapacitating circumstances. It is likely that we would require significant evidence of the circumstance and would consult with administrators and/or academic advisors before granting any further extensions. Your grade could be affected, and it is possible that you would be required to take an incomplete grade.

To grant yourself a one-day extension under this policy, use the late-day registration form. Please do so by 00:30 (thirty minutes after the deadline) if possible. You may grant yourself multiple one-day extensions for a single project if that turns out to be necessary.

A note on the Simics license

Your use of the Simics simulation software takes place under a software license. Before using Simics for anything other than 15-410 class assignments, please see the instructor to ensure that your planned activities are in accordance with CMU's license.

Recording of lectures

Classroom activities may be taped or recorded by a student for the personal use of that student or for all students presently enrolled in the class only, but may not be further copied, distributed, published or otherwise used for any other purpose without the express written consent of the instructor(s).

Reminder About This Document

This document sets forth specific policies and mechanisms for this class. You must also read the companion document on high-level Expectations.

Acknowledgements

Ideas (and even some text) were stolen from Greg Kesden's 15-412 syllabus and Randy Bryant & Hui Zhang's 15-441 syllabus.


[Last modified Monday January 14, 2008]