Labs provide you with an opportunity to apply many of the key ideas we explore in this course. Your lab work will be marked by your tutor, and feedback provided.

Labs are worth 20% of the final mark. There are five labs, each marked out of 10. The lab mark will be calculated as:

\[\mathrm{labTestTotal} = 20 \times (\sum_{i=1}^{5} \mathrm{lab}_{i})/(5 \times 10)\]

All labs are due Fridays at 6pm; the first lab is due Week 3. Labs are submitted via GitLab.

To get started, fork the COMP3300 labs repository into your own namespace in GitLab.

Do not change the name of this project. When the project is cloned for marking, we will use your UID and this exact project name, so if you change the project name, your labs will not be marked. We have created a directory for each lab and also a starting point for each lab question. Do not modify their names or locations; just modify the files (then add, commit, push) to complete your lab solution.

We have created a VirtualBox image that has most of the software we use installed and running. See kernel development via virtualbox.

All source code submissions must include your name in a comment; this is referred to as “authorship details” below.

The labs have a number of stages. Stages have marks next to them, typically ranging from 1-3 marks. The following marking guide will be used :

Criteria Indicative mark
A correct and clear solution 3/3, 2/2, 1/1
Most of the solution complete although functionally not completely working or some limitations in the clarity of the solution 2.5/3, 1.5/2, 1/1
An attempt at the solution that shows some understanding of the requirements 1.5/3, 1/2, 1/1
No attempt or what is done would not help in solving the problem 0/3, 0/2, 0/1

Unless otherwise specified, the only file we will mark is the provided lab\* report. It should have enough information to refer back to it and easily reproduce the whole exercise (say 5 years from now). That means:

  • if you modify an existing source file, you should only include the file’s name and relevant code excerpts for your changes/additions/deletions. Include line numbers if it is a large file. Not the whole file’s contents itself!
  • if you need to create your own file, add the pertinent code in your report; standard header file sequences, debugging code etc. should not be included.
  • you may include the whole file separately in your repo for your own records, but do not expect it to be marked.
  • you should include details on how you tested your work, and the evidence that it worked (e.g. commands and pertinent excerpts of the output)

And the labs:

Updated:    12 Jul 2021 / Responsible Officer:    Director, School of Computing / Page Contact:    Josh Milthorpe