|
Ok, the other night I looked into upgrading the tap
stuff in 2 ways.
1. Providing a tap listener id (not tap id already
inside the tapping core) from the same number space as the protocol
id.
2. Allow taps to register fields to "prime" prior
to dissecting a packet
1. tap listener id's from protocol
id's
The protocol (and field) id's are their
position inside a large array of hfinfo*.
Can it be guaranteed that instances of tap
listeners will be created after *all* protocols and protocol fields have been
registered? This includes plugins.
If so, a seperate counter can be used that
starts with the value immediately following the last hfinfo*, and never inserted
into the array. That should be fairly straightforward.
If not, then
a. something must make it
so
b. tap listeners register with a
NULL hfinfo* - this will require users of get_nth and similar to be able to
handle the case when they are passed a null pointer...
c. tap listeners register with a
NULL filter _expression_... making them unfilterable. This requires some
mechanism of bypassing the no duplicates requirement.
d. having tap listener id's
start at MAX_INT and count down, and simply have an error detection for if the
two ends ever meet.
Currently, register_tap_listener already
returns a string. I don't know that the proper style would be for adding a
second return parameter. Should one be by reference? Or should the
error string be obtained from a seperate function call when the returned id is
invalid (similar to errno)?
2. priming capability
dfilters already use an array of integers,
and a length parameter to hold a list of field id's to prime. Holding an
analogous data structure inside of the tap subsystem should be trivial.
The problem is to figure out what the best way to do so would be. Should
these two new parameters be added to the register_tap_listener call? That
is already fairly long and will only get longer. If yes, the problem is
easy to solve. If not, I would probably lean towards first implementing
#1, and then moving on to implementing this feature... that way a listener can
call a function to add fields to watch for. In some ways, I like that
approach better... it removes the rarely used parameters from the normal
function call.
Any alternate suggestions are welcome and
encouraged.
| 
