Hi,
Technically there is no real reason to have both build in and plugin style
dissectors. The reason they're there is more of an Ethereal origin... (pun
intended).
A little history first. When Wireshark 1.0 came out it had 29 plugin
directories. They came into existence when dissector contributions were made,
developed as plugin for the reason listed (development speed). Seeing
this growing out of hand, especially with the many single source file
dissectors, there was an effort made to fold these single source file dissectors
back into the build in set.
Why only these? First of all it was easier to do. Secondly, and this is still
relevant today, the multi source file dissectors usually 'pollute' the name
space by exporting symbols only used amongst themselves. When building these are
individual modules, these names aren't visible, but when build in they will be.
Furthermore there have been cases in which specific requests were made for
plugins to remain as such (ASN.1 and Profinet come to mind), so that these could
be easily replaced/updated in closed/proprietary environments (without the need
for a whole Wireshark rebuild/distribution).
Last but not least they provide a valuable learning tool, a reference for
dissector plugin writers. doc/README.plugins refers to them, and gryphon
specifically as 'the original plugin'[1]
So, the standing Best Common Practice is to roll simple dissectors (usually
single source file) into the build in set, while keeping the complicated, more
messy stuff isolated in their own little space called plugin.
Thanks,
Jaap
[1] http://anonsvn.wireshark.org/viewvc?view=revision&revision=1341
On 06/20/2011 07:36 AM, Roland Knall wrote:
Hi
Personally, I would prefer changing more or all plugins into built-in
dissectors. It would help those dissectors, who have to use
functionality only provided by a plug-in, as the whole
openSAFETY-SercosIII mix-up showed. My next favorite would be the
ProfiNet plug-in. If no one else would like to do it, I will make the
necessary changes and send in a patch.
I will follow Michael Mann's route with the SercosIII plugin in this
case, first compiling everything together into one, and then moving
the code.
kind regards,
Roland
On Sun, Jun 19, 2011 at 6:21 PM, Anders Broman
<anders.broman@xxxxxxxxxxxx> wrote:
Hi,
I'm not sure if we want to convert all plugins to builtin ones but the asn1
plugin should stay as a plugin and I would think at least one more simple
one as a plugin example.
More comments any one?
Regards
Anders
________________________________
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of
mmann78@xxxxxxxxxxxx
Sent: den 19 juni 2011 16:59
To: wireshark-dev@xxxxxxxxxxxxx
Subject: [Wireshark-dev] plugins to builtins
Why would a plugin dissector ever be better than a builtin? I see
"development speed" mentioned as a plus, but isn't the lack of "platform
independent code" a much greater detriment?
Is there any reason why the current plugins couldn't be converted to
built-in dissectors? I dove in and converted some of the simpler ones
(thanks to Anders for the integration), but before I try and tackle the
harder ones, I wanted to make sure there wasn't something I'm missing about
the process. To me it mostly looks like files need to be moved and
makefiles need to be modified. Not a hard task, but a somewhat tedious.
So far the only issue I've seen is that some of the "more complex" plug-ins
have "subdissectors" each in there own file, but usually not that much
code. As Roland noted
in https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5990#c2, there is
understandably some desire to keep the number of dissector files to a
minimum. Does that just turn into "developer preference"?
Mike Mann
