Removed it.

   - oops, now its fixed!
* vmcd/GNUmakefile.in:
   - linked to math lib as well...

   - compilation fixes

   - added the final code necessary to fully handle a vmc client.

Cleanup rmcd a bit:

	* GNUmakerules: Quick fix to the "check" target.

	* robots/rmcd/rmcd.c, robots/rmcd/test_rmcd.sh.in: Cleanup the
	code a bit, add some comments, etc...

Rmcd and garcia stuff:

	* configure, configure.in: Add robot related template files.

	* robots/GNUmakefile.in: Add primotion directory.

	* robots/emc/emcd.c: Debugging printfs, check the status for
	update-position messages from rmc, and add a basic handler for
	emulab clients.

	* robots/emc/test_emcd.sh.in: Update for changes in mtp.

	* robots/mtp/mtp.h, robots/mtp/mtp.c: Changes for the garcia.

	* robots/mtp/mtp_send.c: Fixes so that it will compile under
	linux.

	* robots/primotion/GNUmakefile.in: Makefile for building a fake
	gorobot in the testbed tree.

	* robots/primotion/Makefile: tweaks

	* robots/primotion/gorobot.cc: First draft with sort-of working
	networking code.

	* robots/primotion/test_gorobot.sh.in: Test case for the fake
	gorobot.

	* robots/primotion/dgrobot/GNUmakefile.in: Makefile for building a
	fake grobot class in the testbed tree.

	* robots/primotion/dgrobot/grobot.h: Add #if !defined(GROBOT_SIM)
	conditionals.

	* robots/primotion/dgrobot/grobot_sim.cc: Empty impl of grobot
	class used for testing.

	* robots/rmcd/GNUmakefile.in: Targets for building rmcd and
	running its test case.

	* robots/rmcd/rmcd.c: First draft with sort-of working networking
	code.

	* robots/rmcd/test_emcd.config: emcd configuration for the rmcd
	test case.

	* robots/rmcd/test_rmcd.sh.in: Test case for rmcd.

pid/eid argument.

Minor cleanup:

	* robots/emc/test_emcd.sh.in, robots/mtp/mtp_send.c,
	robots/mtp/mtp_test.c: Bring up-to-date with the latest version of
	mtp stuff.

	* robots/vmcd/vmc-client.c: Add "valid" field to the mezz stub
	struct.

	* robots/vmcd/vmcd.c: Some compile fixes...

* emcd.c:
   - minor changes, mostly comments. this is next to fix up.
* vmc-client.c:
   - minor changes to tell vmcd about the last packet in a frame
processing cycle (via MTP_POSITION_STATUS_CYCLE_COMPLETE being set in the
last update_position packet of a frame processing cycle).
   - maybe other stuff...
* vmcd.c:
   - massive changes to handle tracking of robots from data passed from
vmc-client, and to handle ID association.
* mtp.h:
   - addded MTP_POSITION_STATUS_CYCLE_COMPLETE #define
   - updated structs request_id and update_id to include a `request_id'
field so that we can uniquely track requests (since they're asynchronous).
* mtp.c:
   - revamped code for above mtp.h changes.

Oops, here's the changes to mtp.h to add support for 64bit timestamps.

info from other mtp structs, added support to encode 64bit floats.

Frame out vmcd:

	* GNUmakerules: Fix "check" target so it runs more than one test.

	* robots/emc/emcd.c: Send the vmc config packet out when vmcd
	connects.

	* robots/vmcd/GNUmakefile.in: Add vmcd-related stuff.

	* robots/vmcd/test_emcd.config: Emc config for the test case.

	* robots/vmcd/test_vmcd.sh.in: Simple test case for vmcd.

	* robots/vmcd/vmcd.c: Initial framing of vmcd, just receives and
	dumps packets, actual logic still needs to be put in.

least get the rest of the users.

have to set $UID=$EUID for sshtb as root to work right.

Temporarily treat garcia 'hosts' like stargates.

Add support for mica1 motes.

real ones (doh!).

assume it always has its default OSID (from node_types) loaded and
ready to go (add this as the OS- feature). This so assign will agree
to the allocation (assign_wrapper adds a desire that says it has to be
running the OSID the user has selected, or the default OSID from the
node_types table).

Watch out for problems ...

stargate and running uisp there.

Untested so far.

Unfortunately, tbuisp now needs to be setuid root because it has to
ssh into the stargates as root. So, take some precautions, like taint
checking and dropping root privs before running uisp locally, to
mitigate the risks.

Start on vmc:

	* configure, configure.in: Add vmcd related template files.

	* robots/GNUmakefile.in: Switch order of vmcd/rmcd.

	* robots/emc/GNUmakefile.in: cleanup

	* robots/mtp/GNUmakefile.in: Add mtp_dump tool.

	* robots/mtp/mtp.c: Change mtp_encode_packet to use a passed in
	buffer pointer or allocate a buffer if its NULL, probably gonna be
	a big source of errors...

	* robots/mtp/mtp_dump.c: Another command-line tool that connects
	to a server and dumps mtp packets that are received.  Useful for
	seeing output from the vmc-client.

	* robots/vmcd/GNUmakefile.in: Add vmc-client and test case.

	* robots/vmcd/test_vmc-client.sh.in: Test case for the vmc-client.

	* robots/vmcd/vmc-client.c: First cut of the vmc-client, it reads
	mezzanine output and sends it to any connected clients.

desktops, nodes, etc.

Thanks to Tim for actually writing most of this code.

subnodes - this was only a good idea in the IXP case. Instead, skip
reloading if they do not have their imageable bit set.

'rebootable' flag set to 0.

	source tb_compat.tcl
	set ns [new Simulator]

	tb-elab-in-elab 1
	tb-set-inner-elab-eid two-simple
	tb-set-security-level Red

	$ns run

tbsetup/ns2ir/elabinelab.ns has all the goo, which is sourced from the
NS run subroutine, using "uplevel 1" so that the context is correct.
You can of course include you own goo, in which case the default goo
will be skipped.

Make the dots move on the robot map web page:

	* configure, configure.in: Add robots/emc/loclistener.

	* event/lib/event.h, event/lib/event.c: Add some helper functions
	for sending events and parsing args.

	* event/lib/tbevent.py.tail, event/lib/tbevent.py: Add support for
	clients that register using keyfiles.

	* robots/emc/GNUmakefile.in: Install loclistener on boss.

	* robots/emc/emcd.h, robots/emc/emcd.c: Send update events every
	two seconds with the node's location.  Fill out a little more of
	the event callback, not sure what to do with the requested
	destination though.  Add some code to the vmc callback to store
	position updates.  Changed the config file format to also include
	the vname of the robot.

	* robots/emc/loclistener.in: Listen for NODE MODIFY events with
	coordinates and update the database accordingly.  Kinda sucks, but
	it works.

	* robots/emc/test_emcd.config: Add vnames to the robots to reflect
	change in the config file format.

	* tbsetup/ns2ir/node.tcl: Add nodes to the virt_agents table.

 (Console interactive robot driving program)

Major fixes to grobot. Added facilities to track goto moves, and avoid multiple gotos from executing at once. Also added functions for estimating final positions after executing a goto command.

 (Console interactive robot driving program)

ElabinElab experiments that wrap another experiment, either firewalled
or not. This instead of my security level stuff, that I decided was
too much of a pain the user, at least for now. New NS syntax:

	tb-set-inner-elab-eid two-simple

In the ElabinElab file, sets the name of an existing experiment in the
same project. Experiment is parsed, and after the parse we notice in
tbprerun that we have an inner eid, so we reparse the NS file, only
this time we pass in the maximum number of nodes needed by the inner
eid (tbprerun now computes min/max nodes at prerun time, instead of
later as first part of swapin). This number is used to allocatethe
appropriate number of inner experimental nodes. Why do it this way?
Cause the NS parser is the only tool we have for generating the virt
topology, and I do not want go down the path of inventing a new
frontend.

Anyway, after the reparse, we now have the proper number of nodes in
the wrapper experiment. Now its simply a matter of copying over the
type and fixnode info from the inner experiment to the outer
experiment.  Why? So that when the outer experiment is swapped in, it
gets the nodes (of the right type/fixnode) that the inner experiment
is going to want later, when it is swapped in by the inner emulab!

Another approach would be to make elabinelab and elabinelab_eid
options to batchexp (and thus the web form and XMLRPC interface) so
that we can avoid the double parse. I suspect people do not want more
crap on the web form, so I did not do it this way.

firewall node and disable the rules during the inner elab setup, and
then turn them back on after the inner boss has rebooted. In the case
that an experiment is to be launched inside, launch the experiment
async and then turn rules back on. Technically, this should be proxied
through the firewall instead of directly, but this is okay for now.

As for experiment teardown, I am not doing anything yet since the
closed firewall lets ssh through, and thats all I need to teardown the
inner elab.

Also during teardown, if DHCPD cannot be killed on inner boss, then
skip rest of the steps and return okay so that the rest of experiment
teardown proceeds (if need be, inner nodes will be power cycled). Not
being be able to kill DHCPD can happen for lots of reasons (like,
experiment never setup in the first place).