anchor.diff:  also checks to ensure that there are no user cycles generated when we are
   running in kernel mode, which could be caused by a hung progress.
   
  +
  +=== Running multiple tests and dependencies
  +
  +=== Correctness vs. Grading
  +
  +=== Multiple output strategies
  +
  +`test161` supports different output strategies through its PersistenceManager
  +interface. Each TestEnvironment as a PersistenceManager which receives
  +callbacks when events happen, like when scores changes, status change, or when
  +output lines are added. This allows multiple implementations to handle output
  +as they wish. The test161 client utility implements the interface through
  +its ConsolePersistence type, which writes all input to stdout. The server uses
  +a MongoPersistence type which outputs JSON data to our mongo backend server.
  +
  +
   == TODOs
   
   === Nits
  
positive.code: * Configuration sanity checks
  * sys161 version checks
  
  === Running multiple tests and dependencies
  
  Support for loading a bunch of tests from a directory and running multiple
  tests concurrently, probably identified by a tag. (You might want to look at
  this parallel walk library: github.com/MichaelTJones/walk)
  
  For test dependency traking my idea is to have all tests start in parallel in
  multiple goroutines but then wait on a channel until all of their
  dependencies are met (or one fails, in which case the test will abort). To
  control concurrency, they should next wait on a separate channel for a
  message from a concurrency manager that can limit the number of `sys161`
  instances executing in parallel.
  
  === Multiple output strategies
  
  We want to support printing to the screen (not the JSON, but output that
  looks like what you'd see in the terminal) and saving JSON output to a
  MongoDB instance for later grading.
  
  === Primitive success or failure tracking
  
  This isn't grading, which is more
  fine-grained, just a sense of whether the test(s) completely successfully and
  didn't panic. I'm working on standardizing the OS/161 test output to make
  this easier so that every test prints a SUCCESS or FAILURE message on exit,
  but we still need to grab panics.
  
  commands.go has the building blocks for determining this. Expected output is
  specified using golang templates.  Also, random inputs can be generated in
  this way as well. Some things that still need to be done:
  
  * Master commands template yaml file, which will get updated as the output
  is fixed in os161
  * External output references (i.e. triplehuge referencing huge)
  * Integrating this with Tests and, eventually, submissions.
  
  === Support for GDB backtraces on error
  
  It should be possible to automate the process of hooking up a debugger and
  running BT on panics.
  
  
  === Targets/Submissions
  
  This needs to be fully designed.  Some considerations:
  
  * Multiple target types, e.g. assignments, performance
  * Grading
  * Integration with TestGroups (which work)
  * Output format
  * Submission metadata
  * Test specification
  * Argument overriding (see commands.go)
  * Short-circuit setting - when to stop the test?  when to skip dependencies?
  
  === Security
  
  The os161 side is in working condition, though we need still need to modify
  userspace binaries and add secprintf to userspace.  In test161, we need to
  verify output lines when we see the secure 4-tuple. Still to do:
  
  * Key generation
  * Overlay file copying
  * Key substitution
  * Key verification
  
  === Client & Server Binaries
  
  * Client Local test runner
  * Client sumbission
  * Server daemon
  * Server stats?
  
negative.code: ....
  $ /bin/true
  ....
  
  === [tags]Test Tags
  Optionally, tests can have one or more tags. `test161` can be invoked to run these tests
  as a group with `test161 run <tag>`.
  
  === Progress Tracking Using `stat161` Output
  
  