> Right now, the hash tables are attached to the protocol field in
> the register routines for the TCP and UDP protocols, which means
> that the register routines for protocols that run atop TCP and
> UDP can't use this unless their register routines happen to be
> called after those for TCP and/or UDP; we may want to have the
> registration with the parent protocol done by separate routines,
> with all the initial registration routines called first, and all
> the register-with-parent-protocol routines called after that
> (which would also let us get rid of the hack wherein we call
> "init_dissect_rpc()" before calling "proto_init()").
Done.
Any protocol that wants to register its dissector to be called when
field "proto.XXX" is equal to YYY should add a routine
"proto_reg_handoff_ZZZ()", which calls
disector_add("proto.XXX", YYY, dissect_ZZZ);
I've done that for DNS; "packet-dns.h" no longer declares
"dissect_dns()" and, in fact, "dissect_dns()" is now static - UDP has no
clue that DNS even exists, until "proto_reg_handoff_dns()" is called,
and even then all it knows is that there's an entry in its dissector
table.
We should do that for other protocols under TCP and UDP.
"make-reg-dotc" will find the handoff registration routines, and make
the routine "register_all_protocol_handoffs()" in "register.c" call all
the ones it finds, just as is done for "proto_register_ZZZ()" routines.
I'm not particularly wedded to "proto_reg_handoff_ZZZ()" as a name (the
reason why it's "reg", not "register", is to keep "make-reg-dotc" from
thinking they're protocol registration routines rather than protocol
handoff registration routines).
The plugin mechanism could conceivably be changed to use this as well -
"check_plugin_status()" could look for a "plugin_register_handoff()"
routine and call it after calling its "plugin_init()" routine, or
perhaps the handoff registration could be done in the "plugin_init()"
routine. (This'd work fine for plugins that register a handoff with a
non-plugin protocol; for plugins registering a handoff with a plugin
protocol, it'd be a bit more complicated.)
