-* Test pintos with GSX.
-
-* Get rid of warnings for NDEBUG build.
-
-* Need targets for checking single tests or single subdirs
-
- - `make check' should say how to get more information
-
- - `make recheck', `make clean-check'
-
-* Need to put time limits on tests.
-
-* Add a way for students to prints messages ignored by the autograder.
-
- - Ignore text between /* and */.
-
- - Allow for a comment on `exit' lines?
-
-* Improve automatic interpretation of exception messages.
-
-* Remove names from synchronization primitives? They don't seem
- useful in practice.
-
-* debug_backtrace() in kernel should only dereference valid pointers.
-
-* Mention how to use add-symbol-file in gdb.
-
-* We need better and more example programs.
-
- - Need an mmap example program as a replacement for the crappy mmap FAQ
- question.
-
- - How about `diff' and `cmp' programs?
-
-* Threads:
-
- - mlfqs tests suck. They aren't even correct, e.g. the amarv
- submission from win0405 is graded incorrectly.
+* In grading scripts, warn when a fault is caused by an attempt to
+ write to the kernel text segment. (Among other things we need to
+ explain that "text" means "code".)
+
+* Reconsider command line arg style--confuses everyone.
+
+* Internal tests.
+
+* Godmar: Extend memory leak robustness tests.
+ multi-oom should still pass in project 3/4 because kernel will run out
+ of kernel pool memory before running out of swap space.
+
+* Godmar: Another area is concurrency. I noticed that I had passed all
+ tests with bochs 2.2.1 (in reproducibility mode). Then I ran them
+ with qemu and hit two deadlocks (one of them in rox-*,
+ incidentally). After fixing those deadlocks, I upgraded to bochs
+ 2.2.5 and hit yet another deadlock in reproducibility mode that
+ didn't show up in 2.2.1. All in all, a standard grading run would
+ have missed 3 deadlocks in my code. I'm not sure how to exploit
+ that for grading - either run with qemu n times (n=2 or 3), or run
+ it with bochs and a set of -j parameters. Some of which could be
+ known to the students, some not, depending on preference. (I ported
+ the -j patch to bochs 2.2.5 -
+ http://people.cs.vt.edu/~gback/pintos/bochs-2.2.5.jitter.patch but I
+ have to admit I never tried it so I don't know if it would have
+ uncovered the deadlocks that qemu and the switch to 2.2.5
+ uncovered.)
+
+* Godmar: There is also the option to require students to develop test
+ workloads themselves, for instance, to demonstrate the effectiveness
+ of a particular algorithm (page eviction & buffer cache replacement
+ come to mind.) This could involve a problem of the form: develop a
+ workload that you cover well, and develop a "worst-case" load where
+ you algorithm performs poorly, and show the results of your
+ quantitative evaluation in your report - this could then be part of
+ their test score.
+
+* Godmar: the spec says that illegal syscall arguments can be handled either by
+ terminating the process, or by returning an error code such as -1.
+
+ Looking at http://gback.cs.vt.edu:8080/source/xref/tests/userprog/write-bad-ptr.c
+ and http://gback.cs.vt.edu:8080/source/xref/tests/userprog/write-bad-ptr.ck
+ I'm wondering if write-bad-ptr isn't forcing them to terminate the
+ process(?). Even though write-bad-ptr.ck has a provision to allow
+ continuation after returning -1, wouldn't it still fail since the test
+ executes:
+ fail ("should have exited with -1");
+ ?
+
+* Godmar: mmap-inherit needs a IGNORE_USER_FAULTS since we say to "not output
+ any messages Pintos doesn't already print." - which technically puts
+ the onus on us to ignore the default page fault msg whenever a test is
+ expected to fault.
+
+* Godmar: add _end to user.lds script and construct some tests that fail
+ unless students check a region for validity rather than just the first
+ address of a region. Right now, unfortunately, they pass all p2 tests
+ with just checking the first address. [A possible problem is that the
+ tests may be unable to tell termination due to unintentional fault
+ from willful termination when address check fails. Should we require
+ they return -1/EINVAL on a bad address and disallow termination? Or
+ construct a test that they'll likely fail if they unintentionally
+ terminate, maybe while holding the filesystem lock? Or require that
+ the diagnostic message only be output when fault occurs in user mode?
+ Something to think about.]
+
+* Threads project:
+
+ - Godmar:
+
+ >> Describe a potential race in thread_set_priority() and explain how
+ >> your implementation avoids it. Can you use a lock to avoid this race?
+
+ I'm not sure what you're getting at here:
+ If changing the priority of a thread involves accessing the ready
+ list, then of course there's a race with interrupt handlers and locks
+ can't be used to resolve it.
+
+ Changing the priority however also involves a race with respect to
+ accessing a thread's "priority" field - this race is with respect to
+ other threads that attempt to donate priority to the thread that's
+ changing its priority. Since this is a thread-to-thread race, I would
+ tend to believe that locks could be used, although I'm not certain. [
+ I should point out, though, that lock_acquire currently disables
+ interrupts - the purpose of which I had doubted in an earlier email,
+ since sema_down() sufficiently establishes mutual exclusion. Taking
+ priority donation into account, disabling interrupts prevents the race
+ for the priority field, assuming the priority field of each thread is
+ always updated with interrupts disabled. ]
+
+ What answer are you looking for for this design document question?
+
+ - Godmar: Another thing: one group passed all tests even though they
+ wake up all waiters on a lock_release(), rather than just
+ one. Since there's never more than one waiter in our tests, they
+ didn't fail anything. Another possible TODO item - this could be
+ part a series of "regression tests" that check that they didn't
+ break basic functionality in project 1. I don't think this would
+ be insulting to the students.