anchor.diff:  * 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:
  +userspace binaries and add secprintf to userspace.  In test161, we currently
  +verify output lines when we see the secure 4-tuple, but the keymap still
  +needs to be generated during the build. 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?
  +* Check for unique salt values during validation
  +
  +=== Server Binary
  +* Server stats API
  
positive.code: 
  == Configuration
  
  == Usage
  
  `test161` requires a set of arguments. The following can be provided either
  on the command line or in a YAML configuration file:
  
  * `root:` or `--root`: the location of a directory containing the kernel
  binary to test and any associated executables that are required, probably
  `~/root/` or `~/os161/root` depending on how you have configured your OS/161
  source tree
  * `tests:` or `--tests`: a list of directories containing testing scripts.
  
  == Requirements
  
  
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
  
  