checkin

[Eddie Kohler]

- renamed gui_faction to cfaction as we talked about (but had second
thoughts: would plug_faction be better???)

- added an initial queue class

- implemented a first try at reference counting packets; see below

- implemented provides/requires, including a relaxation algorithm that
checks provides/requires for an arbitrary graph

- moved noutputs() and output(int) from cfaction to faction, with default
implementations that return 0 and null. this means that provides/requires
checking can work over factions, not just cfactions. am thinking of moving
set_output(int) to faction as well, w/ a default implementation that
returns an error code. then "class cfaction" would only exist to provide
default implementations for a vector of outputs

THINGS TO THINK ABOUT

- template container classes: should we pull in a vector class from
somewhere, or just keep implementing via new and delete?

- multiple uses of the same packet: say that a faction returns the same
packet twice. this leads to issues.

   = each of the downstream branches annotates/modifies the packet. should
they see each other's annotations/modifications?
   = if not, how to implement this? should a packet be
"copy-on-modify-or-annotate"? or should the faction which branched (which
returned the same packet twice) do the copy at that point? should the copy
include a copy of the data?
   = say that, sometimes, the same packet pointer can be passing through 2
branches. should it be allowed to be on 2 different queues? (probably
obviously yes)

what we decide here has implications on the packet freeing story.

- current packet freeing story: once a packet is seen by the driver, the
driver takes responsibility to free it eventually. it does this through a
sort of reference counting. while the packet is in the driver, its
reference count begins at zero. this refcount is increased when it enters a
queue, and decreased when it leaves. when the driver finishes running, it
checks the refcount of every packet it has seen, and frees those with 0
refcount. this does have some problems, we should talk about it.

- we should discuss the queue story. the problem i'm thinking of has to do
with requirement checking:

                                       queue
    [source] ----> [parseip] ------> ]]]]]]]]] ------> [route]
                  provides IP                        requires IP

Problem: This is not a single pipeline; it's two, with two heads: [source]
and [route] (or you can think of the queue as a head). So requirements
checking, which works on a single pipeline, would break here, since when
the second pipeline was checked, it wouldn't realize that the queue
"provides IP" (since all inputs to the queue provide IP).

Proposal: In the initial construction phase, the queue is somehow informed
about everyone who's listening to it. It stores this information and
returns it as `outputs'. (Of course it doesn't allow these outputs to be
set.) Then for purposes of requirements checking this pipeline appears as
one pipeline, even though when the thing is actually run, packets will stop
and hang out in the queue for a while.

love,
ed