Operating Systems - Practical Work: 2011 / 2012
News
Check back here regularly for updates. Earth-shattering news will be mailed to registered participants as well.- 03-04-2012: this year's (6-ECTS) course is starting! Please attend the introduction meeting on Apr 4, 10:15am in M6.07.
- 12-04-2012: if you are interested in doing a replacement assignment for this course, please mail one of the supervisors listed below!
Exercises
This practical is divided into two separate exercises, each adding functionality to a different part of the MINIX 3 operating system. Both exercises are required to pass the class. The first exercise adds kernel functionality (profiling). the second one adds file system functionality (defragmentation).| Exercise | Title |
| 1 | Process Profiling |
| 2 | File System Compaction |
You may work alone, although groups of two persons are encouraged. Groups larger than two are not permitted. You must register by sending an e-mail to Matty Huntjens.
You are advised to start with exercise 1 as soon as possible, as you may (read: will) bump into several obstacles.
Assistance
Information is mainly provided by the following sources:- These WWW pages (http://www.cs.vu.nl/~bs/)
- The MINIX 3 source code (available in the book and on the MINIX 3 website)
- The MINIX 3 book (Operating Systems - Design and Implementation, 3rd edition)
- For general information on MINIX 3, see the official website: http://www.minix3.org/
- Your supervisors: Cristiano Giuffrida, Raja Appuswamy and David van Moolenbroek. IMPORTANT: Please send your questions (in English!) to bs@cs.vu.nl rather than one of us individually. The primary contact method is e-mail. If needed, arrange an appointment.
Assistants can give a limited amount of help. Discussing a design or implementation plan with the supervisor can be useful. If needed, arrange an appointment. Before you ask for help from an assistant, be sure to have read all the relevant documents (like the ones listed on this page). Also make sure you've tried all possible solutions first.
Please note that while the course lasts until the end of August, the assistants may be less responsive during the Summer months due to holidays, internships, etc.
Infrastructure
The practical is based on the book version of MINIX 3 (see OSDI, 3rd ed.), enhanced with a few changes, which are described below. (See the book CD-ROM or download the CD-ROM image here.) This version is preinstalled on the computers in the MINIX 3 lab, room P4.29. Assume the following infrastructure:- Before you start working you can clean up the machine using mnx_fresh. This command puts the system in a known state by synchronizing with a stable copy of the original configuration. Any files that were modified will be refreshed. If the system is truly messed up (e.g., file systems are corrupted), you can create a boot floppy on a working machine using mnx_floppy (or download the 1440 KB floppy image here) and revive the system using mnx_reinstall.
- You are supposed to make modifications to only /usr/src/ and the subtree below. Any other changes will not be considered when you submit your work. However, be careful not to change important configuration parameters that may affect the number of processes, virtual terminals, or our networked testing environment. For exercises that request application programs, store your solution in /usr/src/extra/.
- A clean copy of the original source tree is present under /usr/origsrc/. This may come in handy for reference purposes and is used to track your changes. The easypack packages diffutils-2.8.1 and patch-2.5.4 have been installed (in /usr/gnu/bin/) to work with recursive diffs. In addition, the disk editor (in /usr/src/commands/de) has been patched for exercise 2 (see de.patch).
- You can get an archive with the changes you have made using mnx_diff (found in /usr/local/bin/, like the other mxn_ scripts). This command creates an output file containing all the modifications you made to MINIX 3. Note that only modifications to /usr/src/ are included. Also note that make clean is automatically run in /usr/src/ to remove unwanted files. Use this tool to make backups and/ or submit your solution for testing.
- Finally, the utility mnx_submit allows you to submit your solution for testing. This command assumes an archive like the one created by mnx_diff as input and stores your solution in our database. As an aside, do not build your own tar-file. Only if you use the mnx_diff script, can you be reasonably sure our test routines will accept the archive.
Intermediate Testing
It is required that your program supports a minimum functionality before your work can be considered eligible for further grading (i.e., source code and documentation reviewing). For that reason we have developed some scripts to test your programs. Experience has shown that most submitted work does not pass our tests the first time.To prevent you from being surprised by failing our tests after submitting your final version, you can submit your code for each of the exercises for testing up to three times a month. You can submit each at any time (using mnx_submit); we will send back the test results as soon as possible. Unfortunately we have other work to do too, so it may take about a week in some cases.
On failure of the tests, you will only be told what kind of error was encountered. You can discuss ways to find the error and your testing plans with your supervisor. A precise description of where, why, and how the tests failed will not be given! The tests are not meant as an aid to help you test and debug your implementations. They are meant only as a way to warn you if your current implementation is not to be accepted. You should therefore test your implementation THOROUGHLY before submitting it.
Notes on submitting:
- You have to generate a separate patch file for each of the exercises that you want to submit for testing. This will prevent side-effects in one exercise from affecting the results in another one.
- Clean up your patch as much as you can. We may reject your submission if it contains more than strictly necessary. In particular, remove any non-text/huge files.
Submission Deadline
The deadline for submitting your exercises for final grading is Fri Aug. 31, 2012, 23:59:59. Submit your code using the normal mnx_submit procedure. Documentation describing the project should be sent as a separate document, preferably in PDF format, to <bs@cs.vu.nl>.The deadline is hard. Late submissions will not be accepted. We don't care if your pants were on fire, or if your dog ate your harddrive, or if your taxi was late, or if there were not enough MINIX 3 machines available, NO EXCEPTIONS!
Grading
Your submission is eligible for grading only if it passes the basic test suite. However, this does not guarantee a grade >= 5.5, as source code and documentation still need to be reviewed. Submitted work is usually tested and graded in the first weeks of September. The grade is made up as follows:- Up to 3 points for passing our extensive-test suite.
- You will get up to 3 points for your source code.
- Another 3 points for your documentation.
Since a third of your grade depends on the documentation, you should give a great deal of care to it, and not postpone writing it until the last moment. The documentation should be in English and about 2-3 pages per exercise. It should provide insight in the issues encountered during the exercises and demonstrate that you understand the problems at hand. In other words, why did something go wrong, why did you choose a particular solution, and how did you verify its correctness, rather than only describing the final solution. For example, next to describing your final solution, this solution may well be illustrated by a description of earlier solutions that failed. Assume insiders as the audience, and write for them. As such, leave out trivialities that are mentioned in the assignment and the man-pages. However, make sure that the documentation is self-contained.
Since your source code will be thoroughly examined and graded, it is advised that your code looks clean, and with very clear and abundant comments. This means that you should put to use what you learned in earlier programming courses. Experience has shown that students forget them. However, more importantly, when modifying the sources try to stick to the original style. Another important aspect of modifying sources is that you should try to keep your modifications small, local, and efficient. Failure to take these points into account will inevitably result in low scores for the source code!