new readme about the dev/test cycle for entd

README.devtest

Index: README.devtest
diff --git a/README.devtest b/README.devtest
new file mode 100644
index 0000000000000000000000000000000000000000..b17f73c929544f89eba3c1e77404981f79dd9a7c
--- /dev/null
+++ b/README.devtest
@@ -0,0 +1,89 @@
+
+Entd Development/Test Cycle
+===========================
+
+Most entd features and fixes can be devloped and unit tested entirely in the

[gauravsh, 2010/07/21 17:50:37]

s/devloped/developed/

+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 versioin 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.
+
+