15-410 Project 3 Hand-in

General Considerations

Please make sure early that you have enough AFS quota to hand in your project (see below for location).
We have had some questions about late-day strategy. This is the most important and conceptually challenging project in the class, and the remaining assignments all have a substantially lower effect on your grade than this one.
Do turn in a kernel which runs. That is, when we boot it, it should automatically proceed to running the shell. There should not be any breakpoints in the idle process, for example. Our testing process will feed commands to the shell and observe what happens...this won't go very far if simics is stuck at the command prompt.
Do NOT turn in a kernel which prints thousands of messages to the log file every time it runs. A reasonable amount of traffic is ok, especially if it is restricted to exceptional conditions. Or, if you're looking for a simple rule, most processes should launch, run, and exit without generating 20 lines of kernel log traffic.

This does not mean you cannot have more debugging information, but it does mean you will need some way of controlling how much of it you show to us during grading. We won't grade you on whether your mechanism is crude or sophisticated, but you might benefit from the latter.
When the deadline arrives, we will write-lock your hand-in directory. You will continue to be able to view the contents.
If you need to take a late day for Project 3, use the Late Day Registration Page, by roughly 00:30 (it helps us if you do this as soon as you know, i.e., you don't need to wait until 00:30). Assuming your message is received, the next morning somebody will unlock your hand-in directory so you can again save your work. Of course, your request must be in accordance with the policy published in the syllabus.

Final Submission

Your files should be placed in your mygroup/p3 directory. We should be able to
cd .../p3 ; make
to build your project. This means your files should not be stored in .../mygroup/p3/p3 or .../mygroup/p3/proj3 (to mention two popular naming schemes we observed for P1 and P2). Remember, if you run into "trouble with AFS", please refer to About your 15-410 AFS Space.
Please review the "General Considerations" above.

Checkpoint One

Your files should be placed in your mygroup/p3ck1 directory. Remember, if you run into "trouble with AFS", please refer to About your 15-410 AFS Space.
File format: you may provide us with any one of the following:
1. Plain-text p3ck1/DESIGN file. Please make sure it's called p3ck1/DESIGN, not something else like p3ck1/DESIGN.txt, p3ck1/Design, etc.
  
  We think this format may not be the best use of your time, since your final product will need to be in doxygen, but we will accept this for Checkpoint One if you prefer. If you do this, please provide us with a Unix-format text file (wrapped lines, \n instead of \r\n line ends, etc.).
2. PDF p3ck1/design.pdf file. Please make sure it's called p3ck1/design.pdf, not something else like p3ck1/DeSiGn.PdF, etc.
  
  We think this format may not be the best use of your time, since your final product will need to be in doxygen, but we will accept this for Checkpoint One if you prefer. This format might be useful if you would like us to read pseudo-code you have placed in multiple source files: make sure the files are included in make print, which will provide you with a kernel.ps; you can then use ps2pdf to generate a PDF file and rename it appropriately. This format might also be useful if you did your design work using an outliner or word processor.
3. Doxygen output in a p3ck1/doc/html directory. Please make sure you provide us with the whole doxygen output directory but nothing else. We will start reading p3ck1/doc/html/index.html.
What we're looking for:
1. Information on your key data structures, such as your PCB/TCB, data structures you plan to use to manage virtual and physical memory, etc. We are interested not only in the "guts" of these data structures, but also the methods you plan to use to access and manage them, how and when you plan to allocate and free them, etc.
2. Evidence that you understand the tricky parts of individual system calls and trap handlers. You do not need to provide us with a doxygen version of the Project 3 handout--we already know what print() should return if it's passed invalid arguments, for example. You may not need to provide us with any Checkpoint One documentation for print() at all--we would prefer that you spend time explaining how minclone() will work--a rough outline and some idea of what the hazards, hard parts, or design issues are. Again, don't worry if you overlook or don't document some simple thing; we want you to think about everything, of course, but for this checkpoint you should focus on identifying and designing the hard parts.

[Last modified Saturday January 10, 2004]