15-410 Project 4 Hurdles
Since the kernel project is the core experience of the class, it is important to complete it in a solid fashion. Furthermore, Project 4 involves extending your Project 3 kernel, which requires a solid, debugged base from which to proceed.
Thus, when you reach the Project 3 deadline, you will gauge your degree of completion. Groups with solid kernels will proceed to Project 4, and groups needing extra time to genuinely complete their kernels will receive a 0% grade for Project 4 and will continue working on Project 3 until the "p3extra" deadline of Wednesday, April 20th at 23:59.
Leaping the "hurdle" means that your kernel can pass the "shell test", 14 out of 17 of the basic tests, 8 out of 11 of the solidity tests and 1 out of 2 of the stability tests. Furthermore, your kernel's preemptibility and concurrency control must be reasonable--it is possible to get your kernel to pass more tests by structurally or artificially limiting preemption, but concurrency management will be a significant part of your Project 3 grade, so skipping past that and going to Project 4 will almost certainly be cheating yourselves... Also consider other issues which can't be directly observed by tests. For example, did you get your kernel to "work" by some non-sustainable short-cut? If you couldn't figure out how to safely free kernel stacks, leaking them instead might make things appear to work, but would not really address the problem.
If a particular test, when run on a freshly booted kernel, causes a crash sometimes but not other times then this indicates an instability which you should probably count as a failure. At least, there is a good chance we will observe the crash and count it that way!
Once you've run the tests, please send us a report (success or failure) via the Project 4 Registration Page. Also, be sure to keep a record of which tests you believe you passed and failed in case we disagree later.
Note that it is possible for one or more tests to have a bug. If you think there is a bug in a test, or you believe a particular test relies on a specification ambiguity, submit a careful and detailed bug report to us via e-mail. If failing this test would not disqualify you from P4, go ahead and submit the registration page. Otherwise, indicate in your mail that the test is blocking you.
Observe that some tests, such as remove_pages_test2, pass if your kernel kills the process. That is, they should not run to completion. These tests will announce themselves by emitting the string START__TYPE_ABORT when they start up. Tests announcing START__TYPE_FOREVER should "hang" (really: run forever) instead of completing.
The tests have been released into your 410_user/progs directory.
shell (should run ok, should run commands ok--lots of them!)
deschedule_hang exec_basic (uses exec_basic_helper) fork_test1 fork_wait getpid_test1 halt_test loader_test1 ls (a build-in shell command) mem_eat_test print_basic readline_basic remove_pages_test1 sleep_test1 stack_test1 wait_getpid wild_test1 yield_desc_mkrun
exec_nonexist fork_bomb fork_exit_bomb fork_wait_bomb loader_test2 make_crash (uses make_crash_helper) mem_permissions minclone_mem new_pages register_test remove_pages_test2
cho (mixes wait_getpid, wild_test1, exec_basic, print_basic, sleep_test1) cho2 (mixes yield_desc_mkrun, loader_test1, remove_pages_test1, getpid_test1, fork_wait)
Some groups may almost pass by the criteria above and will be trying to figure out what to do, whether to appeal, etc. Here is some advice.
First, figure out where you stand with P3. Here are some kinds of problems, ranked from least important to most important.
[Last modified Wednesday March 30, 2005]