Richard Sharpe wrote:
On Sun, 12 Dec 2004 lroland@xxxxxxxxxxxx wrote:
- rename mate.[dll/so] to zzmate.[dll/so] so it gets initialized as
the very last protocol (so that fields from every dissector can be
used).
Hmmm, this is not so robust. Someone might have a zzzmumble protocol one
day.
...and the plugins are initialized in the order in which
"readdir()"/"g_dir_read()" return them; there is *NO* absolute guarantee
that this order is alphabetical!
Perhaps we should allow a plugin to be placed in a list of modules to
be initialized last (in the order specified in the preference or
whatever).
Secondly, at some stage there could be more than one module that we want
initialized after all the others so they can gain access to all the
symbols and field that will be available.
Note that the initialization process for dissectors is a two-stage process.
In the first stage, the "register" routines for the dissectors are
called, in no guaranteed order. Nothing done in a register routine
should rely on any other dissector or dissectors having been registered
before it or on any other dissector or dissectors *not* having been
registered before it. (Perhaps we should use a random number generator,
seeded from an appropriately random source, to punish dissectors that
*do* assume that. :-))
In the second stage, the "register handoff" routines for the dissectors
are called, in no guaranteed order. Code in a "register handoff"
routine can rely on the register routines for all dissectors, including
itself, having been called. It cannot, of course, rely on any other
dissectors' "register handoff" routines having been called, or not
having been called.
This was necessary in order to allow dissectors to register in dissector
tables created by other dissectors, and to get handles on other
dissectors. It could also be useful for other purposes...
...such as doing all the work that "mate_make_config()" does.
This would, of course, mean that MATE would be registered regardless of
whether "mate_make_config()" succeeded, as the code in
"proto_register_mate()" that registers MATE wouldn't call
"mate_make_config()" and thus wouldn't know whether doing so would
succeed, but, as a London School of Economics dropout[*] once said, "you
can't always get what you want".
[*] The "Prominent alumni" page at the LSE:
http://www.lse.ac.uk/collections/pressAndInformationOffice/alumni.htm
says he "Registered for BSc Econ 1961-1963"; I guess he was too busy
with his other career after that....
Regards
-----
Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev