Re: [Wireshark-dev] Gently migrating to Git + Gerrit
2013/9/20 Gerald Combs > If I understand correctly, the main difference between Chocolatey > packages and NuGet packages from our perspective is that the former are > installed in system-wide locations (primarily %ProgramFiles%) and the > latter are installed in the local source directory. Which would be > preferable for building Wireshark on Windows? > On my side I would prefer having a system-wide location if I can avoid putting more stuff in my %ProgramFiles% folder as my system disk is filling way too fast. Do we have the possibility to change the target folder (like the WIRESHARK_LIB_DIR environment variable we have today)? 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] Gently migrating to Git + Gerrit
On 20 September 2013 08:04, Pascal Quantin wrote: > 2013/9/20 Gerald Combs > >> If I understand correctly, the main difference between Chocolatey >> packages and NuGet packages from our perspective is that the former are >> installed in system-wide locations (primarily %ProgramFiles%) and the >> latter are installed in the local source directory. Which would be >> preferable for building Wireshark on Windows? >> > > On my side I would prefer having a system-wide location if I can avoid > putting more stuff in my %ProgramFiles% folder as my system disk is filling > way too fast. Do we have the possibility to change the target folder (like > the WIRESHARK_LIB_DIR environment variable we have today)? > > > I believe the Chocolatey install script in a package can put the files in any location, they just have defaults. Chocolatey is a machine-wide package manager and NuGet seems to be more focused on libraries for specific apps, hence targeting the app source directory. We have a mix of requirements, the (possibly machine-wide) infrastructure (VS, cygwin, python, CMake??, etc.) and then the libraries to link with (gtk, glib, qt etc.) so I'm not certain which tool is best, but it would seem that as Chocolatey has a wider range than NuGet it may be more appropriate. I still haven't looked into CoApp yet. ___ 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] Gently migrating to Git + Gerrit
On 20 September 2013 01:16, Guy Harris wrote: > > On Aug 8, 2013, at 11:21 AM, Evan Huus wrote: > > > Similarly on Mac, it would be nice if the macosx-setup.sh script could > > as much as possible be replaced with a set of homebrew packages (or > > some other equivalent). > > On OS X and Windows, it would be nice if people doing Wireshark > development were not required to install a third-party package manager, but > I might be willing to put up with it. > > Unfortunately the required environment for building on Windows is not normally available, even on a "developers" machine so using a package manager would really simplify build environment setup for folks. Chocolatey is a one-line install, and then we could have one other command e.g. cinst wireshark-build-deps to install a "virtual" package that pulls in in everything else that is needed and not already present. There are 3 phases to getting a successful build on Windows; setting up build environment, retrieving build packages and then build. Currently we only have manual written instructions for the first part and the second and third are done in a mix of nmake and cygwin shell scripts. Moving to CMake is an opportunity to rework all of this. (On OS X and Windows, it would be unacceptable, as far as I'm concerned, to > require people to install a third-party package manager in order to *use* > Wireshark, so presumably we'll still be *bundling* third-party packages > ourselves in the distributed versions. > > Definitely. ___ 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] Support for UDP multiplexing and deflate encoding with SIP (Facetime)
I've been spending some time looking at some of the significant changes Apple has made to Facetime in iOS 7. I'm far from an Apple fanboy but some of them are pretty interesting: - multiplexing everything over a single UDP port - deflate compression with SIP - various /slight/ protocol violations ;) More here: http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html I'd be willing to sponsor the Wireshark changes necessary to cleanly dissect this traffic. If you're interested please contact me! -- Kristian Kielhofner ___ 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] [Wireshark-bugs] [Bug 9114] Memory not released when starting a new capture w/o saving last capture
I'd like to discuss the consequences of the remark below in a bit more depth: On Fri, Sep 20, 2013 at 08:27:47PM +, bugzilla-dae...@wireshark.org wrote: > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9114 ... > --- Comment #1 from Jeff Morriss --- > Wireshark intentionally does not free all the memory it had allocated when > closing a capture file. It uses its own memory allocator which allows it to > keep (rather large) blocks of memory around for later re-use (when that > happens > the memory allocator marks all the memory as "freed" but you won't be able to > see that from any OS utilities: they will simply report Wireshark has still > having allocated however much memory). Not freeing that memory is an > optimization to avoid having to re-allocate that memory again when the next > file is read. It this really the right strategy? If I open a huge capture file (with huge allocations) and then open a small file, the (virtual) memory will still be gone. How big is the performance win of not freeing/allocating in real operation? thanks Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ 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] [Wireshark-bugs] [Bug 9114] Memory not released when starting a new capture w/o saving last capture
On 2013-09-20, at 4:40 PM, Joerg Mayer wrote: > I'd like to discuss the consequences of the remark below in a bit more depth: > > On Fri, Sep 20, 2013 at 08:27:47PM +, bugzilla-dae...@wireshark.org wrote: >> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9114 > ... >> --- Comment #1 from Jeff Morriss --- >> Wireshark intentionally does not free all the memory it had allocated when >> closing a capture file. It uses its own memory allocator which allows it to >> keep (rather large) blocks of memory around for later re-use (when that >> happens >> the memory allocator marks all the memory as "freed" but you won't be able to >> see that from any OS utilities: they will simply report Wireshark has still >> having allocated however much memory). Not freeing that memory is an >> optimization to avoid having to re-allocate that memory again when the next >> file is read. > > It this really the right strategy? If I open a huge capture file (with huge > allocations) and then open a small file, the (virtual) memory will still be > gone. > How big is the performance win of not freeing/allocating in real operation? > This is one of the things I looked into with wmem. The performance benefit of not releasing the packet pool between each packet is fairly significant. The performance of releasing the file pool between files is not. Wmem memory is fully released when closing a file. If wmem memory is not being freed when closing a file, that is an actual leak. > thanks > Jörg > > -- > Joerg Mayer > We are stuck with technology when what we really want is just stuff that > works. Some say that should read Microsoft instead of technology. > ___ > 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
[Wireshark-dev] emem -> wmem conversion status and next steps
Hi all, the easy part of the conversion from emem to wmem memory should be almost complete now: dissectors and plugins use the new memory manager (with the exception of uat / initialization routines). Next, I was thinking about converting our helper functions found in epan module and the various ep_ and se_ functions. My idea was to update (and rename!) those functions with the following scheme: tvb_get_ephemeral_string -> tvb_get_wmem_packet_string tvb_get_seasonal_string -> tvb_get_wmem_file_string and adding defines to maintain (temporarily?) backward compatibility: #define tvb_get_ephemeral_string tvb_get_wmem_packet_string #define tvb_get_seasonal_string tvb_get_wmem_file_string Of course we will discover some misuse of ep/se memory (like for uat) that will require more thinking, but it would be one step forward. Thoughts? 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] emem -> wmem conversion status and next steps
On 2013-09-20, at 5:55 PM, Pascal Quantin wrote: > Hi all, > > the easy part of the conversion from emem to wmem memory should be almost > complete now: dissectors and plugins use the new memory manager (with the > exception of uat / initialization routines). > > Next, I was thinking about converting our helper functions found in epan > module and the various ep_ and se_ functions. > My idea was to update (and rename!) those functions with the following scheme: > tvb_get_ephemeral_string -> tvb_get_wmem_packet_string > tvb_get_seasonal_string -> tvb_get_wmem_file_string > and adding defines to maintain (temporarily?) backward compatibility: > #define tvb_get_ephemeral_string tvb_get_wmem_packet_string > #define tvb_get_seasonal_string tvb_get_wmem_file_string > > Of course we will discover some misuse of ep/se memory (like for uat) that > will require more thinking, but it would be one step forward. > I was hoping (at least for functions with both an ep and se version) to make the pool a parameter, so for example tvb_get_string(pool, ...) This can also replace the glib versions of such functions automatically by passing NULL as the pool (wmem provides this "for free"). The macros are a good idea. > Thoughts? > > 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 ___ 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] [Wireshark-bugs] [Bug 9114] Memory not released when starting a new capture w/o saving last capture
On 09/20/13 18:12, Evan Huus wrote: On 2013-09-20, at 4:40 PM, Joerg Mayer wrote: I'd like to discuss the consequences of the remark below in a bit more depth: On Fri, Sep 20, 2013 at 08:27:47PM +, bugzilla-dae...@wireshark.org wrote: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9114 ... --- Comment #1 from Jeff Morriss --- Wireshark intentionally does not free all the memory it had allocated when closing a capture file. It uses its own memory allocator which allows it to keep (rather large) blocks of memory around for later re-use (when that happens the memory allocator marks all the memory as "freed" but you won't be able to see that from any OS utilities: they will simply report Wireshark has still having allocated however much memory). Not freeing that memory is an optimization to avoid having to re-allocate that memory again when the next file is read. It this really the right strategy? If I open a huge capture file (with huge allocations) and then open a small file, the (virtual) memory will still be gone. How big is the performance win of not freeing/allocating in real operation? This is one of the things I looked into with wmem. The performance benefit of not releasing the packet pool between each packet is fairly significant. The performance of releasing the file pool between files is not. Wmem memory is fully released when closing a file. If wmem memory is not being freed when closing a file, that is an actual leak. Ah, OK, it's good to know of that difference from emem (hopefully I can remember it :-)). This particular bug was reported in 1.10 where emem is still heavily used (and emem keeps its memory allocations around like I said--at least while it's using "chunks"). And anyway the reporter says that my explanation doesn't quite cover the problem they're seeing... ___ 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] emem -> wmem conversion status and next steps
On Sep 20, 2013, at 3:16 PM, Evan Huus wrote: > I was hoping (at least for functions with both an ep and se version) to make > the pool a parameter, so for example > > tvb_get_string(pool, ...) +1 ___ 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] Gently migrating to Git + Gerrit
On 9/20/13 2:15 AM, Graham Bloice wrote: > I believe the Chocolatey install script in a package can put the files > in any location, they just have defaults. Chocolatey is a machine-wide > package manager and NuGet seems to be more focused on libraries for > specific apps, hence targeting the app source directory. > > We have a mix of requirements, the (possibly machine-wide) > infrastructure (VS, cygwin, python, CMake??, etc.) and then the > libraries to link with (gtk, glib, qt etc.) so I'm not certain which > tool is best, but it would seem that as Chocolatey has a wider range > than NuGet it may be more appropriate. I hadn't realized that Chocolatey falls back to the official NuGet repositories, i.e. "chocolatey install jquery" downloads the jQuery package from nuget.org and installs it in C:\Chocolatey\lib. This might make managing dependencies a lot simpler. > I still haven't looked into CoApp yet. The part I'm using (AutoPackage) seems to make it easier to create a properly-laid-out NuGet package but we could probably generate the .nuspec files ourselves. The OBS → NuGet scripts are at https://github.com/geraldcombs/wireshark-win-packaging if anyone wants to play with them. ___ 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
