new readme about the dev/test cycle for entd
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/3050009
diff --git a/README.devtest b/README.devtest
new file mode 100644
index 0000000..7e2bae4
--- /dev/null
+++ b/README.devtest
@@ -0,0 +1,89 @@
+
+Entd Development/Test Cycle
+===========================
+
+Most entd features and fixes can be developed and unit tested entirely in the
+source directory of entd while in your chroot. Entd can be built for your
+target platform using only the scons file (no need for emerge or ebuild), and
+can be launched using scripts/run_32bit.sh, or the run_tests.sh script from
+Entd.
+
+To build an x86 version of entd, run...
+
+ $ cd platform/entd
+ $ scons CHOST=i686-pc-linux-gnu SYSROOT=/build/x86-generic/
+
+This will create a platform/entd/out/i686-pc-linux-gnu/ directory and place
+the target executable there.
+
+Then, to launch entd...
+
+ $ ../../scripts/run_32bit.sh ./out/i686-pc-linux-gnu/entd
+ [0721/093224:INFO:main.cc(130)] Starting entd
+ ...
+ [0721/093224:ERROR:entd.cc(471)] Can't determine hostname from username:
+ [0721/093224:INFO:main.cc(208)] Exiting entd with code: 1
+
+Entd takes a number of command line arguments. The error message we just
+got is a sign that we forgot --username. In order to pass arguments through
+the run_32bit.sh script, we need to separate the script's arguments from
+entd's, using --, as in...
+
+ $ ../../scripts/run_32bit.sh ./out/i686-pc-linux-gnu/entd -- \
+ --username=user@example.com
+ [0721/094034:INFO:main.cc(130)] Starting entd
+ ...
+ [0721/094034:ERROR:entd.cc(531)] No policy file.
+ [0721/094034:INFO:main.cc(208)] Exiting entd with code: 1
+
+Here we've failed to start because we haven't specified a policy file, we can
+do that using --policy. Before that, we'll introduce a shell variable to make
+the command lines slightly shorter...
+
+ $ ENTD="../../scripts/run_32bit.sh ./out/i686-pc-linux-gnu/entd --"
+ $ $ENTD --username=user@example.com --policy=test_data/hello-world.js
+
+This time you'll notice that entd doesn't exit on its own. This is an
+unfortunate side effect of the way it catches signals. It's not an issue
+in production, where we expect entd to keep running, but can be troublesome
+for testing. You can add the --allow-dirty-exit, which prevents entd from
+registering to handle signal events, and therefore allows it to exit when
+the policy execution completes. Press Ctrl-C to terminate entd, and then
+run...
+
+ $ $ENTD --username=user@example.com --policy=test_data/hello-world.js \
+ --allow-dirty-exit
+ [0721/094725:INFO:main.cc(130)] Starting entd
+ hello world
+ [0721/094725:INFO:entd.cc(540)] Policy loaded.
+ [0721/094725:INFO:main.cc(208)] Exiting entd with code: 0
+
+And now you've had your first successful run of the Enterprise Daemon. Go you.
+
+For now, entd command line arguments are only documented in source. You'll
+have to read through the top of main.cc for usage information, or read through
+the run_tests.sh script for examples.
+
+The run_tests.sh script runs the entd unit tests, as you might have guessed.
+It's a little janky, but it gets the job done. It's simple to start, and looks
+something like this...
+
+ $ ./run_tests.sh
+ PASS: hello-world.js
+ PASS: bad-onload.js
+ ...
+ PASS: simple-shutdown.js
+ PASS: simple-callback.js
+
+ Tests completed: 28
+ TESTS FAILED: 0
+
+Many of the unit tests require you to have PKCS11 set up in your development
+environment. See the README.pkcs11 file in this directory for details on how
+to get that running.
+
+You should make sure to write new unit tests for any new functionality,
+regression tests for bug fixes, and ensure that all tests pass before submitting
+a CL for review.
+
+
