but if the child thread calls exit(-1) from fatal, the frisbee process
exits, but with a code of zero; i.e., the child exit code is lost.
Granted, a multi-threaded program should not be calling exit willy-nilly,
but it does so we deal with it as follows.

Since the child should never exit during normal operation (we always
kill it), if it does exit we know there is a problem.  So, we catch
all exits and if it is the child, we set a flag.  The parent thread
will see this and exit with an error.

Since I don't understand this fully, I am making it a FreeBSD-only
thing for now.

installs possible).

things for which we previously linked -static.

Fixup some clean targets in a couple of cases as well.

Get capture to compile without SSL (capture-nossl).  This is untested.

This will probably shortly become the default.

control net is not routable.

Comment out an assert that has no purpose than to incorrectly trigger
on OpenBSD.

Rev 20 of the tarball has no new function, it is just slimmed down.
I replaced our large statically linked binaries with dynamically linked ones.
Also found and stripped a couple of other binaries.

The resulting tarball goes from 5.7MB to 0.9MB.

The Makefile changes are to incorporate the NOSTATIC=1 environment hack
to enable building the dynamic binaries above.

 * support FreeBSD 6
 * client-side changes to support enable/disable of ACPI via slicefix
 * use dynamically linked Emulab binaries in frisbee MFS (for size)

<sklower@vangogh.CS.Berkeley.EDU> for the following, related to the -z (zero)
option in imageunzip/frisbee:

  1. For the case where a full-disk image is smaller than
     the disk the image is being unzipped onto, we added
     code to zero the area between the end of the image and
     the end of the disk.

  2. During the unzipping process, when zeros are being written
     at the end of a chunk, a write() that returned a length
     different from the expected value previously caused an
     infinite loop.  We noticed this problem at ISI, on a number
     of pc733s, which we suspect may have (relatively minor)
     hardware disk problems.

The latter addressed a Mike-o that has existed for 4 years.  Call it failure
resilient computing or just plain denial, but because of a botched conditional,
I was ignoring failed writes to the disk.  This lead to one of those infinite loop
thingees if you actually had a bad disk.

* New version of template_record just for ops, since so much is
  different about ops, not bothering to maintain a single version.

* Various fixes to how the recorded events are stored and reconstituted.
  The big fix is to wrap them in a sequence to that they get fired
  properly (waiting for completion of previous event in recording).

* New buttons to Pause and Continue event time, which is used when
  adding recorded events. This allows users to pause time while they
  "think" so when an event is recorded, the thinking time is not actually
  in the timeline. Eventually hope to figure this out automatically, but
  that will take some real, uh, thinking.

* Add a new event editor (linked off the template page) that allows
  you to delete and change the recordings. Note that you can only edit
  the events at the template level; you cannot edit the events of an
  instance (swapped in experiment), and you can only edit the recorded
  events, not any other events. Not sure its useful to be able to do
  either of these yet, but probably not too hard to add at some point.

is already in use, then bind a dynamic port. This will solve the
problem of mixing old clients and a new server since the old clients
will connect to same port that the server will listen on.

Still need to deal with the reverse situation. More complicated ...

Lbs

that clients and servers can avoid using hardwired ports on those
experimental nodes. I have added the following tmcd operation:

	tmcc portregister <service> [<port>]

where we assume its the control network IP (from the DB), and the pid/eid
of the node the experiment belongs to. The given port is entered into
the port_registration table for the experiment, using the service as the
tag. Supplying port=0 clears the registration from the table.

When called like:

	tmcc portregister <service>

we return the registered port, or nothing.

I hacked up a little C library module in libtb so that there is something
that looks like a C interface to this:

 	int
 	PortRegister(char *service, int port);

 	int
 	PortLookup(char *service, char *hostname, int namelen, int *port);

The above routines call out to tmcc of course.

Lastly, I changed the sync server and client to use the new port
registration, via the library calls above.

There are other emulab services that need to be changed as well, but
they can be done on an as needed basis.

draft is that the user will at the end of an experiment run, log into one
of his nodes and perform some analysis which is intended to be repeated at
the end of the next run, and in future instantiations of the template.

A new table called experiment_template_events holds the dynamic events for
the template. Right now I am supporting just program events, but it will be
easy to support arbitrary events later. As an absurd example:

	node6> /usr/local/bin/template_analyze ~/data_analyze arg arg ...

The user is currently responsible for making sure the output goes into a
file in the archive. I plan to make the template_analyze wrapper handle
that automatically later, but for now what you really want is to invoke a
script that encapsulates that, redirecting output to $ARCHIVE (this
variable is installed in the environment template_analyze.

The wrapper script will save the current time, and then run the program.
If the program terminates with a zero exit status, it will ssh over to ops
and invoke an xmlrpc routine to tell boss to add a program event to both
the eventlist for the current instance, and to the template_eventlist for
future instances. The time of the event is the relative start time that was
saved above (remember, each experiment run replays the event stream from
time zero).

For the future, we want to allow this to be done on ops as well, but
that will take more infrastructure, to run "program agents" on ops.

It would be nice to install the ssl xmlrpc client side on our images so
that we do not have to ssh to ops to invoke the client.

conversation with Rob and Kirk yesterday.

already invalid!

Add run time option (-M) to tell it to make imagezip try harder to
optimize metadata saving (aka, the free inode hack).

again.

optimization, this will only affect UFS2 filesystems.

> /*
>  * If DO_INODES is defined, we look at the inode list in each cylinder group
>  * and try to make further space reducing optimizations.  If there are
>  * uninitialized inodes (UFS2 only) we add those blocks to the skip list.
>  *
>  * If CLEAR_FREE_INODES is also defined, we make a more dubious optimization.
>  * Initialized but free inodes will go into the image data, but we first zero
>  * everything except the (usually randomized) generation number in an attempt
>  * to reduce the compressed size of the data.
>  */
> #define DO_INODES
> #undef CLEAR_FREE_INODES

array for every 32-byte entry.  When building a hashfile with 100,000+
entries, this caused quite a bit of moving memory around!

It is still stupid, I just realloc after every 256KB or so.  Need to
eliminate the need to have the whole thing contiguous and maybe the need
to have the whole thing in memory at once!

(as generated by imagehash).  This is Mike's piss-all-over-it version of
Prashanth's implementation of Mike's algorithm.  Delta images are created
by specifying "-H <sigfile>" on the command line.

This is still experimental.

With some work, we might be able to further reduce the image size.