On 06/20/2011 09:47 AM, Roland Knall wrote:
Hi
Regarding the Profinet dissector. Could you point me towards the
discussion, why this specific dissector should stay on as a plug-in?
http://www.wireshark.org/lists/wireshark-dev/200902/msg00241.html
Besides minor bug-fixes which adapted the dissectors to API changes,
no significant changes seemed to have happend in over a year.
But I think it could benefit from being removed as a plug-in. First,
for instance the MRP sub-dissector is actually a stand-alone
dissector, just being put into the same category with the rest, as it
is mainly used in such areas. Second, plug-ins still get missed with
the fuzz-test, at least on my machine.
Then there's something wrong with your machine.
Being able to develop the dissector more easily, I think that held
true, as long as most development machines were rather slow, and
compiling the whole source took some time. Nowadays, recompiling after
initially compiling the dissector takes about a minute for a single
change.
And a mere few seconds for a plugin. This reasoning goes both ways.
That leaves the argument for having smaller files to work with. I
agree, that splitting the dissector code over a bunch of files makes
it easier to work with, but modern IDE's should take care of that.
Modern IDE's, do not make a 100kLOC module better.
Keeping some dissectors as separate plug-ins, but discouraging this
road for new plug-ins just seems to be some sort of favourism, which I
personally reject to.
The reasoning for rolling back single file dissector plugins only have been
given below and above. The exceptions too.
For the ASN1 plug-in the situation may be
different, but Profinet or Ethercat or network protocols like
SercosIII and POWERLINK, and therefore should be treated the same.
Especially if no new development is happening on their part.
kind regards,
Roland
On Mon, Jun 20, 2011 at 9:04 AM, Jaap Keuter<jaap.keuter@xxxxxxxxx> wrote:
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
