Wireshark-dev: Re: [Wireshark-dev] Dynamically loading all dissectors
From: Anders Broman <[email protected]>
Date: Tue, 31 May 2011 21:49:32 +0200
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 [1][2] 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[3]/gtk[4]/ncurses[5])

    b/ our own syntax

Anyone is familliar with other configuration tools?

[1] http://www.cmake.org/cmake/img/CMakeGUI.gif
[2] http://www.cmake.org/cmake/img/ccmake.png
[3] http://www.q-vadis.net/img/homeserver/kernel-xconfig.jpg
[4] http://kerneltrap.org/sup/799/gconfig.png
[5] 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 protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
              mailto:[email protected]?subject=unsubscribe