Wireshark-dev: Re: [Wireshark-dev] media strings and pinfo->private_data

Date: Mon, 24 Nov 2014 11:05:50 -0500
I've made some attempts at understanding the behavior:
 
https://code.wireshark.org/review/5460
https://code.wireshark.org/review/5461
https://code.wireshark.org/review/5462
https://code.wireshark.org/review/5463
 
(There may be some sequential dependencies of these patches on each other)
 
It appears to me that the data parameter of new-style dissectors and pinfo->private_data are interchangeable, so the changes above enforce that.  I believe some of my confusion was from the last time I tried to look at this (several months ago), I tried to come up with a "common structure" that would handle "media string" + "match string" and have that passed between dissectors (so I could possibly eliminate match_string member from packet_info).  Just removing the pinfo->private_data usage was much simpler logic and didn't cause my head to spin as much.
 
 
 
-----Original Message-----
From: mmann78 <mmann78@xxxxxxxxxxxx>
To: wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>
Sent: Sat, Nov 22, 2014 4:41 pm
Subject: [Wireshark-dev] media strings and pinfo->private_data

I'm looking into removing the use of pinfo->private_data in all current dissectors in favor of only using the "data" parameter in new-style dissectors.  The last large remaining use of pinfo->private_data is to pass "string media" between various dissectors.  Some of the "receiving" dissectors (of the string data) support receiving strings through 1 or more of the following methods:
1. data parameter of new-style dissector
2. pinfo->match_string
3. pinfo->private_data
 
Can someone give me the "10000 ft view" of this behavior?  Should I be able to "convert" all pinfo->private_data use into data parameters?  Do the strings end up going through multiple dissectors, so it needs to be "protected" in pinfo->private_data?  Are there inherent relationships between a "pinfo->match_string" string and either the data parameter or pinfo->private_data string?
 
This is stuff I haven't been able to figure out with just code analysis.
 
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe