tcpdump mailing list archives
Re: [tcpdump] After setjmp/longjmp update
From: Bill Fenner via tcpdump-workers <tcpdump-workers () lists tcpdump org>
Date: Wed, 6 Jan 2021 07:56:10 -0500
--- Begin Message --- From: Bill Fenner <fenner () gmail com>
Date: Wed, 6 Jan 2021 07:56:10 -0500
On Tue, Jan 5, 2021 at 8:10 PM Denis Ovsienko via tcpdump-workers < tcpdump-workers () lists tcpdump org> wrote:Bill Fenner via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:I just wanted to share some of my thinking about how to proceed with the truncation-related changes on the road to 5.0.0. 1. Improve code coverage for the printer that's being modified. (This ensures that the code being modified has a corresponding test pcap that can be used by steps 2 and 3).Hello Bill. It used to be 31 test in tcpdump 4.3.0, now it is 571 test, and the coverage is still very far from complete, even more so for less common protocols. There is a steady consensus that it would be nice to have more tests, contributions are welcome as always.My apologies that this statement seems to have been misconstrued. The whole point of this statement about improving coverage was in the context of using trunc-o-matic below. The testing situation *is* improving very impressively and I would not have made this statement standing alone. The point here was meant to be: first you have to make sure you have a pcap that will cause trunc-o-matic to run the code that you're going to change, and then when you change it and trunc-o-matic gives the same result, you can be sure that the code change that you made was correct.2. Use the trunc-o-matic tool from [...] Thank you for proposing this new tool. I see a potential for false positives, let me have some time to try it and to see if that's actually the case.Feedback is absolutely welcome.I also think that community members would be willing to chip in if theeffort was coordinated (e.g., open a github ticket for each printer that needs this conversion, have a wiki page that talks about the conversion process, etc.). There's no need for the maintainers to take on the work of all of the protocols.You mean well, but let me suggest after you walk a mile in these particular shoes you'll prefer a different wording, or maybe even a different idea. Francois-Xavier started this thread in September 2020 on the assumption that community members will want to contribute. It is January 2021 and except myself you are the first ever to discuss, thank you. Let's concur that in foreseeable future there will be a meaningful amount of work that will be never done unless the project maintainers do it.Yes, there will always be a part that nobody will volunteer to do. However, I believe that one reason that nobody has stepped up to participate is that it is not very clear exactly what changes needs to be done and how to measure success. My goal is to lower the bar for external contributions - not to say that I think that there's someone out there who will meaningfully fix print-wb.c, but that I think that there are people out there who could contribute to ospf, bgp, isis, mpls, etc. I realize that I am suggesting to do more work (documentation) in order to reduce conversion work by an unknown amount, which could be zero, so as you suggest I will take a first pass at writing the documentation. A separate ticket for every file to me seems to be not worth thehassle considering how few people need to coordinate now. That said, a weekly/fortnightly status update on the list could be a useful addition.Well, another reason that community members may not be participating could be because it is not at all clear how to avoid duplicate effort. So while a ticket per file may be too much overhead, I do believe some level of communication could help. Right now this is opaque from the outside, so we just end up leaving it all to Francois-Xavier. He has done an amazing job but also deserves some help. Bill
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- Re: [tcpdump] After setjmp/longjmp update Francois-Xavier Le Bail via tcpdump-workers (Jan 03)
- <Possible follow-ups>
- Re: [tcpdump] After setjmp/longjmp update Bill Fenner via tcpdump-workers (Jan 04)
- Re: [tcpdump] After setjmp/longjmp update Denis Ovsienko via tcpdump-workers (Jan 05)
- Re: [tcpdump] After setjmp/longjmp update Bill Fenner via tcpdump-workers (Jan 06)
- Re: [tcpdump] After setjmp/longjmp update Denis Ovsienko via tcpdump-workers (Jan 05)