[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

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