|Main Archive Page > Month Archives > wireshark-dev archives|
Jakub Zawadzki skrev 2011-05-31 20:54:
> On Tue, May 31, 2011 at 11:54:16AM -0600, Stephen Fisher wrote:
>> On Wed, May 18, 2011 at 02:17:33PM -0400, Ed Beroset wrote:
>>> Speaking of more limited platforms, I wonder about about a way of
>>> reducing both startup time and memory usage by having the dissectors
>>> dynamically loaded (as with the current plug-in mechanism) rather than
>>> statically linked. The current model of adding all dissectors to the
>>> main code means that Wireshark will keep getting bigger and bigger. I
>>> wonder if it might not be time to ponder if that's the best possible
>> I thought about this not too long ago, and the problem is that the code
>> to determine which packets belong to which dissector is in the
>> dissectors themselves, so you have to load all of them anyway.
> It's somehow related, so can we rediscuss idea about disabling compilation of some dissectors?
> After exams I'll have some spare time, and I could work on it, but
> I'd really like to have some discussion before.
> Some possibilites how to implement it:
> 1/ lot of new configuration options:
> ./configure --disable-udp --disable-ssl ...
> cmake have got some nice GUIs  for configuration but it can't do tree and dependencies
> (like: disable POP dissector when !TCP).
> 2/ configuration file (easy to backup/restore)
> a/ kconfig - already used by some big projects (Linux, uclibc, Busybox)
> Syntax: http://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt
> And there are already nice tools to do configuration (for Qt/gtk/ncurses)
> b/ our own syntax
> Anyone is familliar with other configuration tools?
>  http://www.cmake.org/cmake/img/CMakeGUI.gif
>  http://www.cmake.org/cmake/img/ccmake.png
>  http://www.q-vadis.net/img/homeserver/kernel-xconfig.jpg
>  http://kerneltrap.org/sup/799/gconfig.png
>  http://www.linux-ipv6.org/~kunitake/zaurus/menuconfig.png
Should we first formulate what the goal is and who would be interested
in that goal? Is
it a problem to have a lot of dissector code on a modern 64bit computer?
Who'd be interested in compiling their own super slim Wireshark and why?
would many people be interested?
Initial memory usage and start up time could possibly be shortened by
excluding a few dissectors
like Diameter, Radius etc which loads files to memory perhaps that
should be configurable?
I would think most people likes the full protocol support to discover
protocols the might not even know they existed. Is thre a significant
gain in speed etc if fewer protocols where present?
> Sent via: Wireshark-dev mailing list<email@example.com>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
Sent via: Wireshark-dev mailing list <firstname.lastname@example.org>