Wireshark-dev: Re: [Wireshark-dev] plugins to builtins
From: Jaap Keuter <[email protected]>
Date: Mon, 20 Jun 2011 09:04:37 +0200
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
<[email protected]>  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: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: den 19 juni 2011 16:59
To: [email protected]
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