[Roland Knall <rknall@xxxxxxxxx>]

Hi

Regarding the Profinet dissector. Could you point me towards the
discussion, why this specific dissector should stay on as a plug-in?
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.

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.

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.

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. 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
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>