The tapping subsystem highly interests me, but I've only just started looking at it :( I'm interested in various extensions of the tapping system. Below are some of my more basic thoughts on tap functionality...
1) I was looking at rpcstat_init and its hard coded link into tethereal. My initial reaction is that there should be a way of handing off a tap string to the tap subsystem for validation. I would also think that the tap initialization core would merely hand off the string (without "rpc," etc...) to a lower level initialization routine... like changing void rpcstat_init(guint32 program, guint32 version, char *filter) /* current preparsed info */ to something like one of the following int rpcstat_init(const char *args) /* let rpcstat parse everything */ int rpcstat_init(guint32 argc, char **argv) /* standard program input argument format? */ int rpcstat_init(guint32 argc, char **argv, char *filter) /* parse out filter expressions */ int rpcstat_init(guint32 argc, char **argv, char *filter, FILE* output) /* why limit to stdout? Probably too text based */ ... various forms depending on how much the tap subsystem handles/parses itself. I would think that such an approach would require yet another register.c/proto_register_XXX-like approach. The method has appeal to me because it allows easier growth of the tap system (even plug-in capability) 2) I can envision the need for a more selective tap calling trigger than a packet of the right type being encountered. It would be nice to have a tap listener called the first time that a packet is processed (or every time except the first time). I imagine that this might be easy to do based on pinfo, but somehow I think that such functionality should not be inside the tap listener, but outside of it. By doing so, it helps guarantee that all taps have a more uniform set of implemented functionality and user interface. Initially I was thinking of potentially having multiple trigger points inside of ethereal to allow the registration/removal of various listeners, but the "update list of packets in real time" feature prevents this method and potentially requires something a bit more advanced. I'm sure that there could be other triggers that I'm not thinking of at the moment... Any and all responses, commentary, rebuttals, etc... are welcome :)
