Wireshark-dev: Re: [Wireshark-dev] [PATCH] Dissector hooks: Small and Simple additions
Hi
Sebastien Tandel wrote:
Couldn't we pass one of the fields in the private data?
Firstly, within the per-field hook/callback, the knowledge about what
the current field is ,will be provided by the hfindex arg, assuming the
hook/callback gets called by one of the proto_tree_add functions and
that is according to my understanding of Guy's reply below.
Secondly, I don't think the hook/callback can be passed any data other
than what is passed as arguments to proto_tree_add_* because a private
data will require initialisation at the dissector level(..before calling
proto_tree_add_*..) and changing dissectors is not considered a good idea.
Regarding the NFS anonymizer, I am thinking of maintaining a global
structure that stores the state about the current Op being dissected. As
and when my per-field hooks are called, I'll keep adding the info from
the current field into this structure.Any other suggestions?
Regards
Shehjar
Regards, Sebastien Tandel
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.
