cs560

ta page

spring 2009

info

• gta: Scott Simmerman
• email: simmerma@eecs.utk.edu
• office: 224e claxton
• office hrs: 9 - 11 am, 3:30 - 4:30 pm thursdays
• lab hrs: 11:15 - 2:15 wednesdays

helpful links

• cs560 Home
• Dr. Beck's CS560
• Dr. Plank's CS360 Lecture Notes

labs

lab 1 - ezshell
• due by noon January 19, 2009
• writeup
• example solution
lab 2 - posix threads (elevators)
• due by noon February 2, 2009
• writeup
• helpful hints
lab 3 - cbthreads (stockroom)
• due by noon February 16, 2009
• writeup
• helpful hints
lab 4 - JOS part 1
• due by noon March 2, 2009
• writeup
• helpful hints
lab 5 - JOS part 2 (multiprogramming)
• due by noon March 23, 2009
• writeup
• helpful hints
lab 6 - JOS part 3 (pipes)
• due by noon April 1, 2009
• writeup
• helpful hints
• lab 7 - JOS part 4 (virtual memory)
• due by noon April 15, 2009
• writeup
• lab 8 - JOS part 5 (demand paging)
• due 11:59:59 PM, April 24, 2009
• writeup

debugging and compiling

For debugging, when printf's just won't do, there's gdb--very handy for tracing through a program. For compiling we use the GNU compiler, gcc. A couple of handy switches for gcc:

• -g: includes symbol information in the executable. This is essential for debugging; without it, gdb is clueless.
• -Wall: Under this option, the compiler will be very verbose with its warnings about questionable constructs in your program. It's always good to compile with -Wall just to catch silly mistakes.

Makefiles make life much easier--they will sometimes be provided for the labs. Here's a sample makefile for lab 1. Check out the GNU documentation site at www.gnu.org/manual for info on gdb, gcc and make.

In most labs you will be using Dr. Plank's Dllist, Jval, and JRB-tree libraries. We have provided static libraries for you to link against under ~cs560/lib. Browse around there and see what you can find.

submitting

To submit a lab:

1. Create a fresh directory and place your source files, makefile and README (if necessary) there.
   DO NOT include .o files, test files, executables or any other extraneous files.
2. From this directory, run the submit script:
   UNIX> 560_submit
3. You will be asked if this is the correct directory and then prompted for the section number and lab number. Once you enter these, your directory will be submitted.
4. You will receive a confirmation email promptly.

Please note...

• Submitting a set of files that will not compile is equivalent to sending a non-working lab.
• Several of Dr. Plank's labs include source files that should not be touched. Either submit copies of those files or symbolic links to those files. Both methods work.
• Make sure that you test out the files you are submitting before running the submission script.
• Also, make sure that you are submitting only source files, a makefile, and a README, if necessary. Deductions will be taken for not following these directives.

style guidelines

All lab source code must adhere to the following style guidelines or points will be deducted. Please feel free to see any of the TAs if you have questions or are unsure your source code is conforming properly.

• Source Code Commenting
  Source Code for each lab needs to be commented. The cs560 TAs are only requiring that you use block level commenting. Comments should be used to give an overview of the code and provide additional information that is not readily understandable from the code itself. It is not necessary that you comment every line in your code. When documenting a program, say only what needs to be said without leaving important things out. We should be able to read only your comments and get a general idea of what your code is doing and how it is doing it.
• Source Header
  All source files (*.c and *.h) should include a main header at the beginning of the file. Minimally, this header should include your name, the class, the lab number and a brief description of what the file contains.
• Function Headers
  All functions need to have a header that includes at least the following information:
  • Function name
  • A brief description of what the function is doing
  • Inputs into the function
  • Outputs from the function
  • Return values and the conditions under which they will be returned
  You are free and encouraged to include more information in your function headers, but the above five pieces of information need to be present. The goal here is to convey to the TA's that you know what your code is doing. As long as you feel that you are doing so, you should be ok.
• Modularity / Function Decomposition
  Most of your cs560 labs are going to require more lines of code than in previous courses and it is important to break your code into functions. A function should perform a specific task or a collection of small highly related tasks. Do not stuff all your code in the main function. Source code is easier to read and debug if it is divided into multiple functions.
• Error Checking
  The following need to be error checked in all labs:
  • All command line arguments (did the user enter what you expected for each argument)
  • Number of command line arguments (are there too many or not enough arguments)
  • Return values of system calls
  If an error occurred make sure to output a meaningful error message to either stdout or stderror and have your program exit gracefully.

grading guidelines

For maximum credit, your lab should (at least) ...

• be commented generously.
• be easy to read and understand.
• output messages that are easy to understand.
• always exit under program control with no OS panics, segmentation violations, I/O errors, etc.
• always initialize variables before use.
• always check function and system call return codes.

Late Labs
Try to avoid late labs at all costs--they cost you 10 points per day plus being a pain for me to keep up with. A key to doing well in this course is to start early on lab assignments and stay ahead of the game.

advice