Wireshark mailing list archives
Re: capture_file* in dissector code
From: mmann78 () netscape net
Date: Wed, 13 Nov 2013 09:41:40 -0500 (EST)
The ulterior motive is actually to reduce members in the packet_info* structure. Some members could be converted to using p_get_proto_data/p_add_proto_data, but the "protocol ID" is required for that API. While I've seen it hacked into a few places in the GUI, I think it's better design if only a dissector has access to that value. The idea is to have the dissectors themselves determine what gets presented in a "Decode As" by registering a "decode as structure". Something of a cross between the dissector_filter(.c) functionality an a UAT. I also thought it could help qt development by providing the data "outside the GUI", reducing the effort there. I'd like the decode_as_ok() (in decode_as_dlg.c) to just loop through an array to determine if there is something to "decode as". As I've looked into it further, the problem is that decode_as_ok() uses dissectors and taps. I was originally just focusing on the dissectors, but knew I needed the "decode as structure" to support a capture_file* in some capacity for the taps (and I've prefer to avoid an architecture that uses void* but the underlying functionality knows exactly what type of pointer it is), hence the post to -dev. -----Original Message----- From: Evan Huus <eapache () gmail com> To: Developer support list for Wireshark <wireshark-dev () wireshark org> Sent: Wed, Nov 13, 2013 9:21 am Subject: Re: [Wireshark-dev] capture_file* in dissector code What does "more generic" mean in this context? On Nov 13, 2013, at 8:15 AM, mmann78 () netscape net wrote: I was looking at making the "Decode As" functionality more generic, but my current solution involves having dissectors handle a callback function that passes in a capture_file* as an argument. Is that valid or does it cross library boundaries creating unwanted dependencies? ___________________________________________________________________________ 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-request () 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-request () 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-request () wireshark org?subject=unsubscribe
Current thread:
- capture_file* in dissector code mmann78 (Nov 13)
- Re: capture_file* in dissector code Evan Huus (Nov 13)
- Re: capture_file* in dissector code Jakub Zawadzki (Nov 13)
- Re: capture_file* in dissector code mmann78 (Nov 13)
- Re: capture_file* in dissector code Jakub Zawadzki (Nov 13)
- Re: capture_file* in dissector code mmann78 (Nov 13)
- <Possible follow-ups>
- Re: capture_file* in dissector code mmann78 (Nov 13)
- Re: capture_file* in dissector code Evan Huus (Nov 13)
- Re: capture_file* in dissector code mmann78 (Nov 13)
- Re: capture_file* in dissector code Evan Huus (Nov 13)
- Re: capture_file* in dissector code mmann78 (Nov 13)
- Re: capture_file* in dissector code Evan Huus (Nov 13)