Guy Harris wrote:
On Feb 21, 2007, at 6:53 PM, Shehjar Tikoo wrote:
It brings in the dissector hooks feature discussed here a few weeks
back. Its a small patch that includes basic infra for hooks and a
sample hook for the NFS dissector.
Right now, the hook gets called(..using call_dissector_hooks()..)
only for NFSv3 setattr call/reply but the intention is to call them
in every message dissector function.
If so, perhaps the hooks should be attached to fields, rather than
inserted into the code of particular dissectors. Having to change
*every* dissector would be a lot of work.
One drawback of a per-field hook could be that hooks which need a global
view or state of the full message might not get access to the needed
fields. For example, when two or more fields inside a single message
need to be correlated in some way, though, I can get around this for the
NFS anonymizer hook.
Regards
Shehjar
My inclination would be to have a list of fields with callback hooks
- most of the time, the list would be empty, so this would, I think,
minimize the added overhead in the usual case - with an entry in the
list having the field's hf_ value, the callback routine, and the
private data pointer to be passed to the callback. Whenever a field
is added to the protocol tree, the list would be checked, and the
hook called if the field in question is being added.
There would be routines to register and unregister hooks.
