* [Outreachy] Internship blog 2020 @ 2020-12-03 2:50 Joey Salazar 2020-12-04 2:47 ` Jonathan Nieder 0 siblings, 1 reply; 4+ messages in thread From: Joey Salazar @ 2020-12-03 2:50 UTC (permalink / raw) To: git@vger.kernel.org, wireshark-dev@wireshark.org Hi all, Very happy to be joining for this winter's internship! A short blog entry on the beginning of this journey here 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! -- Joey ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Outreachy] Internship blog 2020 2020-12-03 2:50 [Outreachy] Internship blog 2020 Joey Salazar @ 2020-12-04 2:47 ` Jonathan Nieder 2020-12-04 3:28 ` [Wireshark-dev] " ronnie sahlberg 0 siblings, 1 reply; 4+ messages in thread From: Jonathan Nieder @ 2020-12-04 2:47 UTC (permalink / raw) To: Joey Salazar; +Cc: git@vger.kernel.org, wireshark-dev@wireshark.org 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?" 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Wireshark-dev] [Outreachy] Internship blog 2020 2020-12-04 2:47 ` Jonathan Nieder @ 2020-12-04 3:28 ` ronnie sahlberg 2020-12-04 3:33 ` ronnie sahlberg 0 siblings, 1 reply; 4+ messages in thread From: ronnie sahlberg @ 2020-12-04 3:28 UTC (permalink / raw) To: Developer support list for Wireshark; +Cc: Joey Salazar, git@vger.kernel.org On Fri, Dec 4, 2020 at 12:47 PM Jonathan Nieder <jrnieder@gmail.com> 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@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Wireshark-dev] [Outreachy] Internship blog 2020 2020-12-04 3:28 ` [Wireshark-dev] " ronnie sahlberg @ 2020-12-04 3:33 ` ronnie sahlberg 0 siblings, 0 replies; 4+ messages in thread From: ronnie sahlberg @ 2020-12-04 3:33 UTC (permalink / raw) To: Developer support list for Wireshark; +Cc: Joey Salazar, git@vger.kernel.org Just a followup to clarify, Take [1] and [2] as good suggestions, then look at other dissectors and mimic them. We are pretty flexible and forgiving when it comes to style and as long as you mostly match what other dissectors look like no one will object. On Fri, Dec 4, 2020 at 1:28 PM ronnie sahlberg <ronniesahlberg@gmail.com> wrote: > > On Fri, Dec 4, 2020 at 12:47 PM Jonathan Nieder <jrnieder@gmail.com> 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@wireshark.org> > > Archives: https://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > > mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-12-04 3:35 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-03 2:50 [Outreachy] Internship blog 2020 Joey Salazar 2020-12-04 2:47 ` Jonathan Nieder 2020-12-04 3:28 ` [Wireshark-dev] " ronnie sahlberg 2020-12-04 3:33 ` ronnie sahlberg
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).