Re: [Wireshark-dev] new dissector - dynamic value string table?
On 2/26/2013 6:51 PM, Guy Harris wrote: > On Feb 26, 2013, at 6:37 PM, Max Baker wrote: > >> The problem I have now is I have different possible values for a >> value_string list, but they are data-dependent. > Why not have multiple value_string lists, then? > Hi Guy, Good question.My example was a bit contrived -- but about 90% of any given list is common to all cameras that support PTP. The last 10% is device-specific.Ideally I just want a way to dynamically add-on the last 10% depending on model. -m ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] new dissector - dynamic value string table?
On Feb 26, 2013, at 6:37 PM, Max Baker wrote: > The problem I have now is I have different possible values for a > value_string list, but they are data-dependent. Why not have multiple value_string lists, then? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] new dissector - dynamic value string table?
Hi All,
I've created a new dissector for USB PTP
(http://en.wikipedia.org/wiki/Picture_Transfer_Protocol) . This is the
protocol most digital cameras speak over USB. I've gotten far enough
to do the basic dissection, and I'm pretty stoked on the results!
The problem I have now is I have different possible values for a
value_string list, but they are data-dependent.
Contrived Example :
0x1 = 'Capture' if Nikon
0x1 = 'Erase' if Canon
To get around this I created a new typedef that I call
value_string_masked. There is a third entry in each row that gives a
mask specifying the type of camera that value is valid for. Shown in
this snippit:
typedef struct _value_string_masked {
guint32 mask;
guint32 value;
const gchar *strptr;
} value_string_masked;
static const value_string_masked usb_ptp_dpc_vals[] = {
{USB_PTP_FLAVOR_NIKON , 0xd010, "ShootingBank"},
{USB_PTP_FLAVOR_CANON , 0xd010, "MeteringMode"}
};
My question regarding creating and using a value_string list on the
fly. Somewhere in the packet stream I'll figure out if it's a Nikon or
a Canon.
1. I need to store that information in an attribute on the USB host.
I'm not sure where to store local values with relation to the data
coming from packet-usb.c
2. I need to create a value_string[] that has only the values that
match my mask, and use that for dissecting.
Can someone recommend an existing dissector I can use as sample code for
this?
I apologize if this is covered in the dev docs already, I'm still
"drinking from the firehose".
Thanks,
-m
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
On Feb 26, 2013, at 2:08 PM, Bálint Réczey wrote: > Exporting all symbols when using more exotic compilers should not be and > issue, > because plugins used on such exotic systems are probably compiled with > GCC >= 4.0, LLVM > or Visual Studio too, and this ensures using exported APIs. Does it ensure that plugins use only exported APIs on, for example: HP-UX, if Wireshark itself is compiled with aCC (as would be the case if the user got Wireshark from the HP-UX Porting and Archive Centre); AIX, if Wireshark itself is compiled with XLC? Sun Studio 8 through Sun^WOracle Solaris Studio 12 appear to support __hidden as a way of saying "not visible outside the library", __global as a way of saying "visible outside the library and references from within the library could bind to code in the application if the application defines it", and "-xldscope=hidden" to make __hidden the default, so that __global overrides it. That sounds as if it'd be what we'd want. It requires us to tweak compiler options when building libraries, but, well, any build-and-configuration tools that can't handle that are toys ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
2013/2/26 Bill Meier : > On 2/26/2013 5:11 PM, Bálint Réczey wrote: >> >> 2013/2/26 Pascal Quantin : >> ... >>> >>> >> >> Thank you! If no one opposes I'll commit the patch on Thursday and >> then start converting the remaining libs. >> > > It sounds like the change is significant. > > if so, I suggest we consider if we should wait until after 1.10 is released > to make the change. It is significant in a way, but I think it would be better to have it in 1.10. It is the last change needed for CMake build system to make it good enough to generate official Debian packages. I got several requests to ship the Qt GUI in Debian and with CMake I can generate both GTK and Qt GUIs nicely not to mention that CMake builds are faster. 1.10.0 would be a perfect candidate to release a fully operational CMake build system for Linux and after 1.10 we could make CMake work on every platform. There is very little downside and if things go bad, we can still revert the changes easily way before the release. Cheers, Balint > > Bill ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
2013/2/26 Jakub Zawadzki : > On Tue, Feb 26, 2013 at 08:46:28PM +0100, Bálint Réczey wrote: >> If you have concerns or comments, please share them. :-) > > Some (older) compilers don't support -fvisibility=hidden can you add test > if this option is accepted by compiler? Sure, I'll add that before committing. Cheers, Balint ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
On 2/26/2013 5:11 PM, Bálint Réczey wrote: 2013/2/26 Pascal Quantin : ... Thank you! If no one opposes I'll commit the patch on Thursday and then start converting the remaining libs. It sounds like the change is significant. if so, I suggest we consider if we should wait until after 1.10 is released to make the change. Bill ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
On Tue, Feb 26, 2013 at 08:46:28PM +0100, Bálint Réczey wrote: > If you have concerns or comments, please share them. :-) Some (older) compilers don't support -fvisibility=hidden can you add test if this option is accepted by compiler? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
2013/2/26 Pascal Quantin : ... > > Hi Balint, > I just tried your patch on my Win32 box (MSVC2010) and it seems to be > working fine: symbols exported by libwsutil.dll are the same before and > after the patch. > > Regards, > Pascal. Hi Pascal, Thank you! If no one opposes I'll commit the patch on Thursday and then start converting the remaining libs. Cheers, Balint ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
Hi Guy, 2013/2/26 Guy Harris : > > On Feb 26, 2013, at 11:46 AM, Bálint Réczey wrote: > >> I have created the attached patch to control symbol visibility using >> C defines instead of .def and .sym files. > > You might want to use comments on #else and #endif to make it a bit easier to > figure out what #else is the opposite of and what #endif terminates. I have updated the patch with the suggested comments. > >> It is expected to work on every platform and every build system we support, > > "Work" as in "not fail to compile", or "work" as in "keep symbols from being > exported outside the library if not marked as being exported by the library"? I would target compiling on every platform first, but in thecases I have tested only the intended symbols got exported. :-) I also had to add more symbols to the list, because tshark did not compile without them. > > At least some UN*X compilers might support GCC-style > __attribute__(visibility(...)) options, but I don't know whether all the ones > that would be used to compile Wireshark, on platforms where the linker can > hide symbols, do. I suggest hiding the symbols where we can hide them by improving the WS_DLL_PUBLIC defines (i.e. where we can do it without relying on libtool). Exporting all symbols when using more exotic compilers should not be and issue, because plugins used on such exotic systems are probably compiled with GCC >= 4.0, LLVM or Visual Studio too, and this ensures using exported APIs. Cheers, Balint ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
2013/2/26 Bálint Réczey > Hi, > > I have created the attached patch to control symbol visibility using > C defines instead of .def and .sym files. It is expected to work on every > platform and every build system we support, but I did not want to > commit it without discussing the direction. > > I have tested it using autotools and CMake, but I could not give it a try > on > Windows or OS X. If you have some time and access to those platform > please test the patch. > > The rationale behind making this change is simplifying the method we > maintain > the set of exported symbols and it is also needed by the CMake build. > AFAIK we can't use the .def and .sym files in CMake. > > If we agree to go this way I'll convert libwireshark and libwiretap, too. > If you have concerns or comments, please share them. :-) > > Hi Balint, I just tried your patch on my Win32 box (MSVC2010) and it seems to be working fine: symbols exported by libwsutil.dll are the same before and after the patch. Regards, Pascal. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
On Feb 26, 2013, at 11:46 AM, Bálint Réczey wrote: > I have created the attached patch to control symbol visibility using > C defines instead of .def and .sym files. You might want to use comments on #else and #endif to make it a bit easier to figure out what #else is the opposite of and what #endif terminates. > It is expected to work on every platform and every build system we support, "Work" as in "not fail to compile", or "work" as in "keep symbols from being exported outside the library if not marked as being exported by the library"? At least some UN*X compilers might support GCC-style __attribute__(visibility(...)) options, but I don't know whether all the ones that would be used to compile Wireshark, on platforms where the linker can hide symbols, do. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Simpifying exporting DLL symbols
Hi, I have created the attached patch to control symbol visibility using C defines instead of .def and .sym files. It is expected to work on every platform and every build system we support, but I did not want to commit it without discussing the direction. I have tested it using autotools and CMake, but I could not give it a try on Windows or OS X. If you have some time and access to those platform please test the patch. The rationale behind making this change is simplifying the method we maintain the set of exported symbols and it is also needed by the CMake build. AFAIK we can't use the .def and .sym files in CMake. If we agree to go this way I'll convert libwireshark and libwiretap, too. If you have concerns or comments, please share them. :-) Cheers, Balint 0001-Export-libwsutil-symbols-using-WS_DLL_PUBLIC-define.patch Description: Binary data ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
