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