Wireshark-dev: Re: [Wireshark-dev] plugins to builtins
From: Jaap Keuter <[email protected]>
Date: Mon, 20 Jun 2011 18:36:15 +0200
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?
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<[email protected]> 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' 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  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