(2) is a Great Idea!

Even easy to fit in...

1) add in proto.[ch]
void proto_register_protocol_prefix_registrator( char* prefix, void
(field_registrator*)(void) ) ;
that stores field_registrators  in a hash indexed by prefix.

2) proto_registrar_get_byname() has just to call the field registrator
whenever fails to find a field. Not very impacting as it gets called
only when a filter is compiled ( i.e. almost each time an user enters
a key in the filter box).

3) move what's not esential in proto_register_xxx() to
xxx_field_registrator(). Leaving in proto_register_xxx()  only what's
esential to eventually get invoked. Last but not least make sure
xxx_field_registrator() gets called before adding any of those fields
to the tree.

At first we just do this with few essential protocols (the very slow
ones I've added, like SNMP, XML & the AAAs (1)) and leave other
protocols (entire families?) for later.

L

(1) Yes, I feel guilty for all the accumulated productive time wasted
by every user every time


On Thu, Mar 27, 2008 at 11:17 PM, Guy Harris <[EMAIL PROTECTED]> wrote:
>
>  On Mar 27, 2008, at 2:35 AM, Luis EG Ontanon wrote:
>
>  > My first thought was at a "delayed" initilalization (initialize just
>  > them when needed, right when the dissector gets called for the first
>  > time), but this has a major drawback not being there at initialization
>  > the dynamic fields from these protocols could not be used in tshark
>  > (or in wireshark up until when the first packet is dissected). i.e.
>  > something like:
>  >    tshark 'radius.UserName == "pippo"'
>  > would not be possible.
>
>  Initialize them just when needed, when either
>
>         1) the dissector gets called for the first time
>
>  or
>
>         2) a display filter reference occurs for a field name that would
>  belong to the dissector, and that field name isn't found
>
>  which would require a way for a dissector to register a "wildcard"
>  field name with a callback.
>
>  That then opens up the possibility doing that for *all* dissectors,
>  which might further speed up startup.
>  _______________________________________________
>  Wireshark-dev mailing list
>  [email protected]
>  http://www.wireshark.org/mailman/listinfo/wireshark-dev
>



-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Reply via email to