> On Nov 13, 2013, at 9:41 AM, [email protected] wrote: > > 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.
Why? I think a few dissectors already share that value for determining the value of the parent protocol (since that is stored as a list of protocol IDs now) and I don't see any particular reason to restrict protocol IDs to just dissector code? > The idea is to have the dissectors themselves determine what gets presented > in a "Decode As" by registering a "decode as structure". I'm missing how this is related to removing items from pinfo. > 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 <[email protected]> > To: Developer support list for Wireshark <[email protected]> > 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, [email protected] 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 <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected]?subject=unsubscribe > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
