On Fri, Dec 4, 2020 at 12:47 PM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > Hi Joey, > > Joey Salazar wrote: > > > Very happy to be joining for this winter's internship! A short blog > > entry on the beginning of this journey here: https://jsal.home.blog/ > > > > A new entry every 2 weeks, check it out! > > > > Thank you Outreachy, Git, and Wireshark for the opportunity, happy > > to be working together! > > Welcome! I'm looking forward to working together (starting with an > initial wireshark patch to get the lay of the land, then fleshing out > the plan for the project, then executing on it in earnest). > > A question for wireshark developers: are there preferences for what a > high quality dissector looks like? [1] talks about portability and > robustness but doesn't address other aspects of convention such as how > long functions should be (like [2] does). Is there a rule of thumb > like "when in doubt, do things the way <such-and-such dissector> > does?" Only speaking for myself. This one is tricky. Most dissectors I think follows [1] and [2] pretty closely, with the exception that I don;t think there is any concern about lengths of a function. For a lot of protocols you may end up with switch statements with hundreds of cases and then that is just how it is. Or similar. Now, this is not uniform across all dissectors. Wireshark has grown organically over more than two decades and styles and preferences, which at the end of the day are dictated by the developers, change. So do not be surprised to find some dissectors that are very different in style. In some cases it might just be that the dissector is very old and also for an obscure protocol that almost no one cares about. Sometimes it is that simple. I would see [1] and [2] as good guidelines but not absolute law. Then also when in doubt look at how are things done in popular protocols where there are many developers involved and where the dissector is well maintained. For example packet-smb2.c is pretty modern and has a fair amount of crunch to keep up with the evolving standard. Modern and popular(i.e. people care about them) dissectors also are much more likely to contain useful examples of more advanced features such as * ExpertInfo, * Preferences, * Reassembly, * lots of Generated items (things that are not part of the packet itself but still useful to show when wireshark deducts it), * state tracking such as keeping track on Request and Response matching and response times. etc etc etc. This makes the dissectors more daunting to look at since there are so many different concepts there ontop of just "show what the bits and bytes mean" but at the same time they show these extra things that we usually have in a good/popular/mature dissector. But at the end of the day, for every protocol, what makes a good dissector is what an experienced engineer would need to do his/her job. I think that means that it takes a lot of subject-matter-expert knowledge to know what is useful and what is not and here you probably have as good or probably better input on what the dissection features should be. Hypothetical example: say if wireshark had a feature where it would reassemble objects and store them under their hash somewhere and it allowed you to right-click on a sha1 in the dissection pane and then "export object as file". Would that be useful? You would know if it would be useful for git developers and engineers. I have no idea. ronnie > > Excited, > Jonathan > > [1] https://gitlab.com/wireshark/wireshark/-/raw/master/doc/README.developer > [2] https://www.kernel.org/doc/html/v5.9/process/coding-style.html > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
