[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7639

--- Comment #12 from Michal Labedzki <michal.labedzki@xxxxxxxxx> 2012-08-20 13:26:32 PDT ---
(In reply to comment #11)
> - Does patch #1 make any actual logical changes, or is it simply moving the
> dissectors to their own directory and making the appropriate build changes? It
> will be much faster to review if I don't have to worry about any logical
> changes to the dissectors themselves.

Wireshark have about 1100 dissectors right now, so hard to see some specific
group of dissectors like modem GSM, Bluetooth, USB. My propose is try to
creating groups if possible. Maintenance should be easier. For example
Bluetooth dissector there are only related to closed-group of "interface", so
you can never see Bluetooth over Ethernet, etc. (yes, yes... we can everything,
but not to fast or ever...). Patch 1 make only this "move", so nothing changed
in real. If nobody see any reason for new directory we can drop this idea, but
next is separation Bluetooth dissectors for build system, this is used in next
patches (patch 2). 


> - We've been trying to avoid using plugin dissectors in the Wireshark source,
> as they don't integrate into the packaging and distribution as nicely and are
> more prone to getting out of sync with the installed Wireshark version. I'm
> surprised that you're finding Wireshark's build system slow - a 'hot' re-build
> of one dissector my box takes well under 30 seconds to complete. That's not
> instantaneous, but it's not painfully slow either, especially given how big the
> Wireshark tree is (and how long an initial clean build takes). All that is to
> say, it's unlikely that the plugin-izing of dissectors that are already in-tree
> will be accepted. We'd much rather take patches that speed up the build in
> general :)

He he :) My rebuild by touch file one of dissector is exactly 20 seconds, so I
am faster. But plugins is Holy Gail for dissectors developers, because you can
rebuild dissectors in "realtime", so no 20-30 seconds (and cry if compilation
error, so 1 minutes for nothing...), than 0-2 seconds - 2 seconds for rebuild
full bluetooth-plugin, but never happen again when built at once. This is much
faster and this way is what I want. I am agree that "static" library of
dissectors is release, but hard for developing. My intention of these patches
is developing dissectors as plugins than integrate into static library in
Wireshark. This should not conflicts with main Wireshark strategy.

In future I want to upload new patch which should add feature to override
internal dissectors by plugins - especially for developers only (checkbox in
preferences?).

> - If you could attach a few sample captures that can be used to test and
> demonstrate your fixes and improvements, that would be greatly appreciated.
> There are two small captures already at [1], but they are hardly comprehensive.

Expect colors there is no any special thing to see, but you can use captures
from these bugs:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6619
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6567

Immediately after this bug I want to upload for review one of my new
dissectors, but now I hesitate because I done changes in build system and I
will be very happy to not rebase one time more. Rather I can deliver pluginized
version of dissector related to changes from this "bug". What do you thing?


> 
> All the best,
> Evan
> 
> [1] http://wiki.wireshark.org/SampleCaptures#Bluetooth

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.