Re: [Wireshark-dev] Remove hf_ variables
On 13 August 2013 17:53, Jakub Zawadzki wrote: > On Fri, Aug 09, 2013 at 08:31:02PM +0200, Jakub Zawadzki wrote: > > On Wed, Aug 07, 2013 at 08:10:21PM +0200, Jakub Zawadzki wrote: > > > I wrote some ugly gawk program for hf_ variables. > > > > > > Here is one + some patch for epan: > > > http://www.wireshark.org/~darkjames/proto-new/0001-changes.txt > > > > > > Here is convertion of some dissectors (not quite automagic): > > > http://www.wireshark.org/~darkjames/proto-new/0002-rewrite.txt > > > > > > We probably don't want this redefine macros inside proto-new.h but > it's *much faster* > > > to test. > > > > Removed in v2: > > > > http://www.wireshark.org/~darkjames/proto-new-v2/0001-changes.txt > > http://www.wireshark.org/~darkjames/proto-new-v2/0002-rewrite.txt > > > > Changes from v1: > > - proto_tree_add_item() now takes pointer to header_field_info *, > >if NEW_PROTO_TREE_API NOT defined small compatilibity macro is used. > > - convert names just to hfi_ not hfi_hf_ > > - fix proto_get_first_protocol_field(), proto_get_next_protocol_field() > > Ping, any feedback? > > Also missing final approval/reject (/me smiles to Gerald) ;] > > It's not entirely clear to me from the thread what the current intent is. Your current plan is just the removal of hf vars? You'll also need to update the docs, README.dissector is the most obvious, then everyone's presentations on how to build a dissector :-) ___ 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] packet_win.c still broken
Hi, On Thu, Jun 27, 2013 at 8:53 AM, Michal Labedzki wrote: > > > > On 26 June 2013 18:19, Jakub Zawadzki wrote: > >> >> (Wow, someone was using it! awesome) >> >> Cheers, >> Jakub. >> > > > Hey, I use it too.I really like it option to modify and save that to file. > It can be used to check another protocol value while writing new dissector. > http://wiki.wireshark.org/GSoC2013 (Packet Editor) > > Maybe experimental options like this should be enabled in development > release, than disabled in release if incomplete. As I know this one is not > broken. > I like the idea of Michal, to add by default packet editor and a preference to enable the feature. I will make more visibility to packet editor... I attach a serie of patch to add packet editor to the default and preference > > > Pozdrawiam / Best regards > > - > Michał Łabędzki, Software Engineer > Tieto Corporation > > Product Development Services > http://www.tieto.com / http://www.tieto.pl > --- > ASCII: Michal Labedzki > location: Swobodna 1 Street, 50-088 Wrocław, Poland > room: 5.01 (desk next to 5.08) > --- > Please note: The information contained in this message may be legally > privileged and confidential and protected from disclosure. If the reader of > this message is not the intended recipient, you are hereby notified that > any unauthorised use, distribution or copying of this communication is > strictly prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and deleting it > from your computer. Thank You. > --- > Please consider the environment before printing this e-mail. > --- > Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w > Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym > Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru > Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. > Kapitał zakładowy: 4 271500 PLN > > ___ > 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 > 0001-Enable-Packet-Editor-by-default.patch Description: Binary data 0002-Add-WANT_PACKET_EDITOR-to-CMake.patch Description: Binary data 0003-Add-Packet-Editor-Preference.patch Description: Binary data 0004-Add-Edit-Packet-in-Right-Click.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
Re: [Wireshark-dev] Interesting thing about "recent" changes in GHashTable
Hi, On Tue, Aug 13, 2013 at 06:15:28PM -0400, Evan Huus wrote: > Not worth it in my opinion unless the memory savings are significant (I > suspect they are only in the range of a few-hundred KB). Yes, something like this. Exact numbers for few: proto_names21KB3 insertions(+), 15 deletions(-) registered_dissectors 8KB 41 insertions(+), 20 deletions(-) eth_hashtable 6KB 51 insertions(+), 76 deletions(-) manuf_hashtable 262KB 64 insertions(+), 25 deletions(-) sub_dissectors 40KB 46 insertions(+), 25 deletions(-) 338 KB in total. (test patches: http://www.wireshark.org/~darkjames/ghashtable-set/) ___ 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] Remove hf_ variables
On Wed, Aug 14, 2013 at 09:26:17AM +0100, Graham Bloice wrote: > On 13 August 2013 17:53, Jakub Zawadzki wrote: > > > On Fri, Aug 09, 2013 at 08:31:02PM +0200, Jakub Zawadzki wrote: > > > On Wed, Aug 07, 2013 at 08:10:21PM +0200, Jakub Zawadzki wrote: > > > > I wrote some ugly gawk program for hf_ variables. > > > > > > > > Here is one + some patch for epan: > > > > http://www.wireshark.org/~darkjames/proto-new/0001-changes.txt > > > > > > > > Here is convertion of some dissectors (not quite automagic): > > > > http://www.wireshark.org/~darkjames/proto-new/0002-rewrite.txt > > > > > > > > We probably don't want this redefine macros inside proto-new.h but > > it's *much faster* > > > > to test. > > > > > > Removed in v2: > > > > > > http://www.wireshark.org/~darkjames/proto-new-v2/0001-changes.txt > > > http://www.wireshark.org/~darkjames/proto-new-v2/0002-rewrite.txt > > > > > > Changes from v1: > > > - proto_tree_add_item() now takes pointer to header_field_info *, > > >if NEW_PROTO_TREE_API NOT defined small compatilibity macro is used. > > > - convert names just to hfi_ not hfi_hf_ > > > - fix proto_get_first_protocol_field(), proto_get_next_protocol_field() > > > > Ping, any feedback? > > > It's not entirely clear to me from the thread what the current intent is. > Your current plan is just the removal of hf vars? I'm not sure what 'just' means, generally yes, but to be sure please check patches above (I'm much more fluent in C than in English ;-)). > You'll also need to update the docs, README.dissector is the most obvious, > then everyone's presentations on how to build a dissector :-) Old registration-style still works. ___ 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] Enabling packet editor (was: Re: packet_win.c still broken)
On Wed, Aug 14, 2013 at 02:41:19PM +0200, Alexis La Goutte wrote: > > Hey, I use it too.I really like it option to modify and save that to file. > > It can be used to check another protocol value while writing new dissector. > > http://wiki.wireshark.org/GSoC2013 (Packet Editor) > > > > Maybe experimental options like this should be enabled in development > > release, than disabled in release if incomplete. As I know this one is not > > broken. > > > > I like the idea of Michal, to add by default packet editor and a preference > to enable the feature. > I will make more visibility to packet editor... > > I attach a serie of patch to add packet editor to the default and > preference I'm fine with these patches (why you need preference option for it?). Still we've discussed this topic already in: "[Wireshark-core] 1.6 branch" thread, and I'm afraid nothing was changed. It was fun project, I no longer need it, and I'd rather drop it rather than enable (code is not so great). We had lot (I counted 4) of GSoC students who wanted to work on packet editor stuff, maybe we pick one next year? Cheers, Kuba. ___ 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] [msvc] 'etype_vals' : unknown size
On Aug 13, 2013, at 9:18 PM, Guy Harris wrote:
> On Aug 13, 2013, at 8:24 PM, DbdM Tbt wrote:
>
>> I would like to update I just now used an SVN checkout of wireshark and
>> error C2133 will not anymore occur.
>> I was mistaken. I didn't expect that I needed the updates to other files
>> aside from etypes.h.
>> About my development situation is that my target is the latest release (of
>> which i assume, meant latest 'stable' release).
>> I will try to ask if the higher-ups will agree to using the development
>> version of wireshark.
>> But in the meantime, I will try to update my working copy with any other
>> files needed to be updated (i.e. ws_symbol_export.h was mentioned).
>
> If by "working copy" you mean your 1.10.1 tree, there are more files for this
> fix than just ws_symbol_export.h, and in order for us to find what files they
> are, we'd have to do the work necessary to backport the fixes in question to
> the 1.10.1 tree. That might be the right thing to do.
I tried, but the resulting version of TShark crashed when the buildbot ran some
capturing tests.
I've attached a patch with the changes. I have no time to try to figure out
what would need to be done, so you're on your own there; note that we don't
develop C++ dissectors as part of the project, and don't guarantee that they'll
work.
Index: ws_symbol_export.h
===
--- ws_symbol_export.h (revision 51352)
+++ ws_symbol_export.h (revision 51353)
@@ -49,33 +49,96 @@
/* Originally copied from GCC Wiki at http://gcc.gnu.org/wiki/Visibility */
#if defined _WIN32 || defined __CYGWIN__
+ /* Compiling for Windows, so we use the Windows DLL declarations. */
#ifdef WS_BUILD_DLL
+/*
+ * Building a DLL; for all definitions, we want dllexport, and
+ * (presumably so source from DLL and source from a program using the
+ * DLL can both include a header that declares APIs and exported data
+ * for the DLL), for declarations, either dllexport or dllimport will
+ * work (they mean the same thing for a declaration when building a DLL).
+ */
#ifdef __GNUC__
-#define WS_DLL_PUBLIC __attribute__ ((dllexport))
+ /* GCC */
+#define WS_DLL_PUBLIC_NOEXTERN __attribute__ ((dllexport))
#else /* ! __GNUC__ */
-#define WS_DLL_PUBLIC __declspec(dllexport) /* Note: actually gcc seems to
also support this syntax. */
+ /*
+ * Presumably MSVC.
+ * Note: actually gcc seems to also support this syntax.
+ */
+#define WS_DLL_PUBLIC_NOEXTERN __declspec(dllexport)
#endif /* __GNUC__ */
- #else
+ #else /* WS_BUILD_DLL */
+/*
+ * Building a program; we should only see declarations, not definitions,
+ * with WS_DLL_PUBLIC, and they all represent APIs or data imported
+ * from a DLL, so use dllimport.
+ *
+ * For functions, export shouldn't be necessary; for data, it might
+ * be necessary, e.g. if what's declared is an array whose size is
+ * not given in the declaration.
+ */
#ifdef __GNUC__
-#define WS_DLL_PUBLIC __attribute__ ((dllimport))
+ /* GCC */
+#define WS_DLL_PUBLIC_NOEXTERN __attribute__ ((dllimport))
#elif ! (defined ENABLE_STATIC) /* ! __GNUC__ */
-#define WS_DLL_PUBLIC __declspec(dllimport) /* Note: actually gcc seems to
also support this syntax. */
+ /*
+ * Presumably MSVC, and we're not building all-static.
+ * Note: actually gcc seems to also support this syntax.
+ */
+#define WS_DLL_PUBLIC_NOEXTERN __declspec(dllimport)
#else /* ! __GNUC__ && ENABLE_STATIC */
-#define WS_DLL_PUBLIC
+ /*
+ * Presumably MSVC, and we're building all-static, so we're
+ * not building any DLLs.
+ */
+#define WS_DLL_PUBLIC_NOEXTERN
#endif /* __GNUC__ */
#endif /* WS_BUILD_DLL */
- #define WS_DLL_PUBLIC_NOEXTERN WS_DLL_PUBLIC
+
+ /*
+ * Symbols in a DLL are *not* exported unless they're specifically
+ * flagged as exported, so, for a non-static but non-exported
+ * symbol, we don't have to do anything.
+ */
#define WS_DLL_LOCAL
-#else
+#else /* defined _WIN32 || defined __CYGWIN__ */
+ /*
+ * Compiling for UN*X, where the dllimport and dllexport stuff
+ * is neither necessary nor supported; just specify the
+ * visibility if we have a compiler that claims compatibility
+ * with GCC 4 or later.
+ */
#if __GNUC__ >= 4
-#define WS_DLL_PUBLIC __attribute__ ((visibility ("default"))) extern
+/*
+ * Symbols exported from libraries.
+ */
#define WS_DLL_PUBLIC_NOEXTERN __attribute__ ((visibility ("default")))
+
+/*
+ * Non-static symbols *not* exported from libraries.
+ */
#define WS_DLL_LOCAL __attribute__ ((visibility ("hidden")))
#else /* ! __GNUC__ >= 4 */
-#define WS_DLL_PUBLIC
+/*
+ * We have no way to control visibility.
+ */
#define WS_DLL_PUBLIC_NOEXTERN
-#define WS_DLL_LOCAL extern
+#define WS_DLL_LOCAL
#endif /* __GNUC__ >= 4
Re: [Wireshark-dev] [msvc] 'etype_vals' : unknown size
Hello sir, It is ok and thank you very much for the assistance. This level of support is even more than what I expected. I will check out the patch and try to use it in my end. Best regards, David On Thu, Aug 15, 2013 at 5:07 AM, Guy Harris wrote: > > On Aug 13, 2013, at 9:18 PM, Guy Harris wrote: > > > On Aug 13, 2013, at 8:24 PM, DbdM Tbt wrote: > > > >> I would like to update I just now used an SVN checkout of wireshark and > error C2133 will not anymore occur. > >> I was mistaken. I didn't expect that I needed the updates to other > files aside from etypes.h. > >> About my development situation is that my target is the latest release > (of which i assume, meant latest 'stable' release). > >> I will try to ask if the higher-ups will agree to using the development > version of wireshark. > >> But in the meantime, I will try to update my working copy with any > other files needed to be updated (i.e. ws_symbol_export.h was mentioned). > > > > If by "working copy" you mean your 1.10.1 tree, there are more files for > this fix than just ws_symbol_export.h, and in order for us to find what > files they are, we'd have to do the work necessary to backport the fixes in > question to the 1.10.1 tree. That might be the right thing to do. > > I tried, but the resulting version of TShark crashed when the buildbot ran > some capturing tests. > > I've attached a patch with the changes. I have no time to try to figure > out what would need to be done, so you're on your own there; note that we > don't develop C++ dissectors as part of the project, and don't guarantee > that they'll work. > > > ___ > 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 > ___ 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
