Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Nachos Project Guidelines: Operating Systems Assignment for Teams - Prof. B. L. Barnett, Assignments of Operating Systems

The rules and requirements for the operating systems assignment in the cmsc 321 course, which is to be completed in teams of three. Teams cannot be dissolved, and team members are responsible for managing internal conflicts. Flexible slip days are provided for assignment deadlines, and revision control and backups are the responsibility of each team. Coding specifications include using #ifdef changed for modifications and documenting all changes. A write-up, including an outline of the project and test cases, is also required. Submission is done through a tarball, and grading is based on design, implementation, and professional polish.

Typology: Assignments

Pre 2010

Uploaded on 08/19/2009

koofers-user-sth
koofers-user-sth 🇺🇸

10 documents

1 / 3

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CMSC321OperatingSystems
NachosProjectMechanics
(ModifiedcopyofNachosProjectMechanicsbyTomAnderson)
Teams:
Theprojectistobedoneinteamsofthree(bythispoint,youhavealreadybeenassignedtoyourteam).
Onceateamisformed,itmaynotbedissolvedexceptforthemostbizarreandunusualreasons.Ifyou
haveproblemswithinyourteam,workthemoutinternally.Teammemberswillgenerallyallreceivethe
samegradeforeachassignment,althoughIwillgiveeachmemberofateamtheopportunitytojudge
thecontributionsofothermembersofthatteamtotheassignment(seelastsectionofthisdocument).
SlipDays:
Youwillhaveflexibleslipdatesfortheassignments.Eachteamisgivenanautomaticextensionof5
calendardays(notclassdays),whichcanbeusedonanyNachosprogrammingassignments,inany
integerincrement,aslongasthetotalamountoflatenessdoesnotadduptomorethan5days.You
mustuseyourslipdaysinintegerincrementsso,forexample,ifyousubmityourassignment12hours
late,thatcountsforoneslipday,notonehalfslipday.(Notethatanyschoolholidays,e.g.,springbreak,
alsocountagainstyourslipdays.)Thisshouldletyouscheduleduedatesaroundtheduedatesforother
courses.Whenyouhandinanassignment,youmustidentifyatthetopoftheassignment,(i)howlate
thisassignmentis,and(ii)howmuchofthetotalsliptimeyouhaveleft.Afteryouhaveusedupyourslip
time,anyassignmenthandedinlatewillbemarkedoff20%perday.Therewillbenoextensions
granted.
RevisionControlandBackup:
Youarecompletelyresponsibleforrevisioncontrolandbackups.Forrevisioncontrolwithinyourteam,
youmaywanttotakeadvantageofthecapabilityofgroupsinLinux(onceteamsaredetermined,Iwill
haveagroupsetupforyou)alongwithrevisioncontrolsoftwaresuchasCVS.(CVSanditsancestor
RCSappearstobetheonlythinginstalledonoursystemscurrently).
CodingSpecifications:
Thenachos1/directorycontainssourcecodeforNachosforthefirstassignmentinthedirectory
threads/,pluscodeforthemachineemulationinthedirectorymachine/.Forthefirstassignment,
youwillneedtomakechangestofilesinthreads/(additionaldirectorieswillbeprovidedforlater
assignments),butyoushouldnotmodifythefilesinthemachine/directory.Also,soIcantellwhat
changesyouhavemade,surroundeverypieceofcodeyoumodifywith:
#ifdef CHANGED
// put your changes here
#endif
Notethatonceyouhavedonethis,youwillneedtohavetheline
#define CHANGED
ineachfile(oracommonheaderfile)inorderforyourchangedcodetobecompiledin.
pf3

Partial preview of the text

Download Nachos Project Guidelines: Operating Systems Assignment for Teams - Prof. B. L. Barnett and more Assignments Operating Systems in PDF only on Docsity!

CMSC 321 — Operating Systems

Nachos Project Mechanics

(Modified copy of Nachos Project Mechanics by Tom Anderson)

Teams:

The project is to be done in teams of three (by this point, you have already been assigned to your team).

Once a team is formed, it may not be dissolved except for the most bizarre and unusual reasons. If you have problems within your team, work them out internally. Team members will generally all receive the same grade for each assignment, although I will give each member of a team the opportunity to judge

the contributions of other members of that team to the assignment (see last section of this document).

Slip Days:

You will have flexible slip dates for the assignments. Each team is given an automatic extension of 5 calendar days (not class days), which can be used on any Nachos programming assignments, in any

integer increment, as long as the total amount of lateness does not add up to more than 5 days. You must use your slip days in integer increments — so, for example, if you submit your assignment 12 hours late, that counts for one slip day, not one‐half slip day. (Note that any school holidays, e.g., spring break,

also count against your slip days.) This should let you schedule due dates around the due dates for other courses. When you hand in an assignment, you must identify at the top of the assignment, (i) how late

this assignment is, and (ii) how much of the total slip time you have left. After you have used up your slip time, any assignment handed in late will be marked off 20% per day. There will be no extensions

granted.

Revision Control and Backup:

You are completely responsible for revision control and backups. For revision control within your team,

you may want to take advantage of the capability of groups in Linux (once teams are determined, I will have a group set up for you) along with revision control software such as CVS. (CVS – and its ancestor

RCS – appears to be the only thing installed on our systems currently).

Coding Specifications:

The nachos1/ directory contains source code for Nachos for the first assignment in the directory

threads/, plus code for the machine emulation in the directory machine/. For the first assignment,

you will need to make changes to files in threads/ (additional directories will be provided for later assignments), but you should not modify the files in the machine/ directory. Also, so I can tell what

changes you have made, surround every piece of code you modify with:

#ifdef CHANGED // put your changes here #endif

Note that once you have done this, you will need to have the line

#define CHANGED

in each file (or a common header file) in order for your changed code to be compiled in.

Write‐Ups:

In addition to your code, I expect the team to submit a written outline/description of what you did for the assignment, explaining and motivating your design choices. Keep the description short and to the

point, but also make sure that it is complete. Of course, you must document your code if you want the reader to understand what you did (a requirement for getting a good grade!). Some assignments have

parts that ask you to explain something about your design; this explanation must also go in your outline/description.

I expect you to run test cases to demonstrate that your code works (or that it doesn’t!). The results of

these test cases must appear in a test‐case description that accompanies the outline/description above, and includes an explanation of what each test case is supposed to show. I will not tell you what test

cases to run — so do not ask. It is up to you to convince me that your code works. You should pick the minimal set of test cases that do so.

Submit your write‐up as a PDF, included in your tarball.

The electronic document must be placed in your top‐level nachos1/ directory.

Submission:

To submit an assignment, create a tarball of your nachos1/ directory and all contained files using

tar -czvf nachos1--submit.tgz nachos1/

where your team name replaces . One member of the team must then submit the tarball to my netfiles inbox.

Grading:

The grading for the project will be as follows: 35% design, 50% implementation, and 15% “professional

polish” (see below). I have structured the grading in this way to encourage you to think through your solution before you start coding. If all you do is work out a detailed design for what you would do to address the assignment (and if the design would work!), but you write no code, you will get 35% credit.

The implementation portion of the grade considers whether you implemented your design correctly, ran reasonable test cases, and provided documentation that the reader can understand. Finally, to

encourage you to come up with good designs (rather than ones that only work), I am assigning 15% of the grade for each assignment to “professional polish points”. The base grade is 85% if your design and implementation work perfectly; you may get additional points if your solution is elegant, simple, and

easy to understand, or if it goes well beyond the requirements of the assignment. If you think you deserve “professional polish points”, you must convince me of this in your write‐up.

Individual Assessment Write‐up:

Each member of the team must also submit an individual write‐up. In this write‐up, list in detail those

aspects of the project for which you are completely responsible; also list those aspects for which you assisted in development.

Also, I will give each team member an opportunity to evaluate the amount of work that other members of the team gave to the project. Specifically, given 20 points total, each team member should divide the points among all team members (including yourself). For instance, if you feel that both members of your