Wow, that sounds awesome.
Question: What is the current layout/structure of the new code? I
imagine one c file per dissector in epan/dissectors/, but where are
all the other c files? Are the capabilities they add shared only
between your protocols, or might they be useful to other protocols?
How big/complex are they? More details on this kind of thing will help
us figure out how best to integrate.
Suggestion: Please please please read through the latest
README.developer and README.dissector and make sure you follow all the
things therein. 90% of the review comments I make are things that are
already mentioned in those documents, so making sure you follow them
makes things go much smoother. Also make sure your code passes the
various scripts (tools/check*) and fuzz-testing as well
(http://wiki.wireshark.org/FuzzTesting). If you have any questions
about style etc please ask in advance rather than wait for somebody to
catch it on review.
Hope this helps,
Evan
On Fri, Jan 31, 2014 at 1:47 PM, David Ameiss <netshark@xxxxxxxxxxxxx> wrote:
> We've developed a set of dissectors for my company's protocols - all based
> on UDP and TCP. I've gotten the OK to submit them to Wireshark, and have
> spent the last 2 months tracking the development changes, keeping things
> current, and just finished moving over to the new git/gerrit approach.
>
> The issue is that these new dissectors are quite substantial - 8 separate
> dissectors, 40 files (22 .c, 18 .h), containing nearly 20,000 lines of code.
> I also have some GUI additions (originally done for GTK, now in Qt) to
> provide analysis and stats capabilities for these dissectors. That adds
> another 6 files and 7,000+ lines of code (plus the 3 .ui files).
>
> As there is a large amount of common functionality that has been factored
> out into separate modules (hence the large number of files), adding in small
> pieces is not practical. The GUI component is obviously independent, and can
> be submitted separately once the dissector component is integrated.
>
> Or, I can submit the whole thing at once.
>
> What's the best approach to ensure the code gets reviewed, rather than
> completely overwhelming the reviewers? :-)
>
> --
> David Ameiss
> netshark@xxxxxxxxxxxxx
> ___________________________________________________________________________
> 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