to get this change in cause it also includes some DHCPD conf changes and
Mike and I were messing each other up.
* The DHCPD change is that instead of using reserved.inner_elab_role
as the flag to indicate a node should boot inside or outside, I
added inner_elab_boot, which is a boolean that I set when its
actually time to do this. This avoids two ElabInElab swapins at the
same time from messing each other up! Basically avoids the obvious
race.
* The rest of the changes are for swapmod itself, which are incomplete
but should be harmless until the rest of the stuff is ready.

used to force the server to send an IGMP report if it doesn't receive any
packets within <seconds> seconds. As long as the server is receiving
packets, it won't send the report.
What I'm not lovin here, is that to send a report I have to drop membership
in the group (socket opt IP_DROP_MEMBERSHIP) and rejoin (IP_ADD_MEMBERSHIP).
Simply trying to do an add membership doesn't work because the kernel thinks
you are already in the group and errs out. I'm hoping all the up and down
activity doesn't make the switch behave any worse than it already does.

agree on how big a disk is. See the comment added for details.
I don't consider this a "critical fix" for others at the moment because the
problem only manifests itself if you load a disk using the FreeBSD 5 MFS
which only we have and the fix didn't get enough testing before the release
went out.

mini images from the webcams (240x180) are displayed in the mechanical
area in the lower right of the floormap. The frame rate is 2fps to
avoid pummeling the node, as its all done with Java, including the
jpeg conversion and display (I grabbed most of this code from my
tools/webcamapplet that I wrote a while back).
My first attempt at this performed really bad cause I was redrawing
the entire display whenever a new frame came into any camera. Ack,
this was chewing 98% of the CPU.
So, I restructured things so that each camera is in its own JPanel and
has its own paint callback. However, in order to have overlapped
JPanels (since the base image is also a JPanel) I needed to shift to
using the LayeredPane instead of the ContentPane of the applet. This
meant creating a wrapper JPanel to hold the base image, and then
combining everything together on the layered pane. The result is that
the repainting system paints only what needs to be painted, and
everything runs much much faster (about 15% CPU on my desktop).
Also got rid of my inline double buffering; JPanels do that by default
for you. I did not realize that at the time I wrote the applet cause I
missed the tiny footnote in the Graphics2D tutorial that says Swing
components do that for you!

transcode a motion jpeg into mpeg (very CPU intensive), I know know
how to alter the camera frame rate on the fly using a wget call. The
downside is that this affects the camera globally (mpeg rate), but
thats okay since the grabwebcams script only allows itself to be run
once at a time to avoid conflict.
Still not hooked into experiment path; waiting for terrabytes of disk
storage!

resolutions) if there turn out to be more than we had initially
estimated.
This was a bit of a bonehead bug - I was under the impression that
indexing into an STL vector would autmoatcially grow the vector to
the size of your index. This turns out not to be the case.