They are modeled after dissection dissector tables, but for the moment, don't have/need the flexibility. They are intended to be much simpler/faster than full dissection.
The two most used/needed are "wtap_encap" and "ethertype", so they were the basis of starting to use and test capture dissector table API. Others may be added in the future.
The "capture dissector" function signature needed a bit of tweeking to handling "claiming" of a packet.
The current application of this is capture functions returning TRUE if they affected a "type" of packet count. Returning FALSE ends up considering the packet an "other" type.
Change-Id: I81d06a6ccb2c03665f087258a46b9d78d513d6cd
Reviewed-on: https://code.wireshark.org/review/12607
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Capture dissectors could be architected like dissection dissectors, with tables and subtables and possibly using tvbs to pass there data instead of raw byte arrays. This is a first step towards that by refactoring capture_info_packet() to work off of a "capture dissector table"
Registering the capture dissection functions instead of calling them directly also clears up a bunch of dissector header files who sole purpose was providing the capture dissection function definition.
Change-Id: I10e9b79e061f32d2572f009823601d4f048d37aa
Reviewed-on: https://code.wireshark.org/review/12581
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Michael Mann