Hi, Couldn't we pass one of the fields in the private data?
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 > _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
