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. _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
