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@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>