[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ethereal-dev
Subject:    Re: [ethereal-dev] Suggestion for changing gtk/main.c
From:       Guy Harris <guy () netapp ! com>
Date:       2000-02-29 20:23:40
[Download RAW message or body]

> Currently (ie the stable 0.8.3 version) gtk/main.c contains the following procedure
> static void
> ethereal_proto_init(void) {
>   init_dissect_rpc();
>   proto_init();
>   init_dissect_udp();
>   dfilter_init();
> #ifdef HAVE_PLUGINS
>   init_plugins();
> #endif
> }
> 
> Doesn't it make more sense to do all the init_dissect_protocol BEFORE 
> proto_init()?

Probably.  The "init_dissect_xxx()" stuff was done somewhat *ad hoc*.

Protocol initialization routines are called in alphabetical order by the
file name of the file containing the registration routine; if they were
called based on a total ordering compatible with a partial ordering in
which, if protocol YYY is encapsulated inside protocol XXX, XXX is
"before" YYY, you could have all a protocol's initialization, including
registering itself with its "parent" protocols, done within its
initialization routine, but establishing that partial ordering in the
build process could be a pain.  (It also presumes there wouldn't be any
cycles - but I suspect there could be cycles, e.g. IP-inside-IP.)

Given that, I'd be inclined either to

	1) make it possible to call protocol XXX's "register a child
	   protocol" routine *before* protocol XXX's initialization
	   routine is called, e.g. by having the "register a child
	   protocol" routine initialize whatever data structures are
	   necessary for that registration, rather than leaving it up to
	   the protocol's initialization routine

or

	2) have a protocol's initialization routine register a routine
	   to be called when all the initialization routines have been
	   called, so that the protocol initialization does

		proto_init();
		call_post_initialization_routines();
		dfilter_init();
	      #ifdef HAVE_PLUGINS
		init_plugins():
	      #endif

Either of these would obviate the need to hardcode into
"ethereal_proto_init()" the list of "init_dissect_xxx()" routines.

> In the case of UDP messages this enables new dissectors to 
> register themselves in the hash using udp_hash_add (provided that this 
> function is added to packet.h or something like that) and it would avoid
> adding every new protocol to packet-udp.c. Just add 
> udp_hash_add(MY_PORT_NUMBER, MY_DISSECTOR) to 
> proto_register_PROTOCOL!

Yes, that should be done for more than just UDP.

(It'd arguably be nice to use the filter-expression-based mechanism
that's used for plugins here; unfortunately

	1) that's currently somewhat expensive, as it requires that the
	   protocol tree be constructed even if it's not going to be
	   displayed

and

	2) it currently requires that a protocol explicitly call a
	   "check for filter-based protocol selection" routine, which I
	   think is currently done only by the TCP and perhaps UDP
	   dissectors.)

[prev in list] [next in list] [prev in thread] [next in thread]