possible to:

	gmake client
	sudo gmake client-install

on a FBSD4, FBSD5, RHL7.3, and RHL9.0 client node.

There are still some dependencies that are not explicit and which would
prevent a build/install from working on a "clean" OS.  Two that I know of are:
you must install our version of the elvin libraries and you must install boost.

(early stages of getting Emulab software to build under FreeBSD 5)

- have pump/dhclient script record the DHCP'ed interface in
  /var/emulab/boot/control_interface

- change control_interface script to first check for that file
  and use the contents if it exists

Note that, as of this commit, we are still telling pump/dhclient which
interface to DHCP on (i.e., we still determine the control net interface
the old way to invoke pump/dhclient) so this commit is not that useful.

What still has to be done is to change the startup to invoke dhclient/pump
on all interfaces.  This turns out to be a royal, royal PITA.

Stay tuned...

of the database).

when doing modelnet. Sure wish we had a better way to do this!

vserver/pcplab). Rather then 10000s of fixed node entries in the DB,
create node entries on the fly as needed (assign_wrapper), and then
delete them when they are no longer used (nfree). When new nodes check
in, no longer create all those nodes table entries (utils/newnode.in
and tbsetup/plab/libplab.py.in).

I've added a new library: db/Node.pm which is something I started a
while back, and decided to commit, along with the support for creating
and deleting virtual nodes. CreateVnodes() creates a new set of nodes,
choosing non-conflicting names in the DB, and then immediately
reserves them to the pid/eid specified. DeleteVnodes takes a list of
vnodes and deletes them from nodes,reserved,etc. This library does a
few other things which I am going to be playing with, so you might
want to go read the comment at the top of the file. Feel free to speak
up. CreateVnodes() is from called assign_wrapper when a node type has
the "isdynamic" property. Otherwise does the existing avail/nalloc
stuff. DeleteVnodes() is called from nfree when the node type has the
isdynamic property.

I've added a script (sql/delvnodes.pl) to run after updating the DB
and software. All free pcvm and pcplab virtual nodes are deleted from
the DB; reserved ones will get deleted whenever their experiment ends.
I've noted all of this in doc/UPDATING, including setting the
isdynamic property on pcvm in the node_types table.

I've left tbsetup/plab/libplab.py.in to create a single pcplab node
for the management sliver (still called -20). We can worry about this
later.

All this for modelnet?

widearea node.

has NULL or "".

created, and which named_setup generates.

boss later anyway.

tried to share it between them.

Cleaned up modules, separating implementations from the headers. Changed ugly g++ 3.* compatability hack into a robust support.

nodes, rather then hardwiring the speed/duplex in delaysetup. We
already started doing this for phys interfaces underlying veth
interfaces, but Mike requested we do this for delay nodes as well so
that we do not hardwire 100Mb into the script.

have a power outlet! At least we will know ...

happy.

differentiate clients.

* Put in debugging timestamps to figure out why so slow.

* Cleanup, fixing bad identing, bad style, bad comments, etc.

* Restructure so that instead of locking three tables (nodes,
  reserved, and node_activity), we just need to lock the reserved
  table, by moving the node existence check to before the main loop,
  and the node_activity update to after we unlock tables. Not locking
  the nodes table results in less serialization and less waiting for
  the lock to be granted.

* XXX: Check each node for an entry in tiplines table; Do not call
  into console_setup.in if none of the nodes have tiplines. This is
  not a very clean thing to do of course, but it saves up to half the
  time it takes to do an nalloc cause of the min startup time for our
  perl scripts (almost 1/2 a second). When allocating virtnodes on a
  physnode, no reason to even call console_setup.in.

Bottom line? Well, not as good as one would like ... time to allocate
10 vnodes on a pnode goes from .8 seconds to .4 seconds ...

which is a pc3000 (aka "wireless node") as configured for our cluster