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
option.
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?
(http://www.wireshark.org/lists/wireshark-dev/201104/msg00316.html)
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?
Regards
Anders
___________________________________________________________________________
Sent via: Wireshark-dev mailing list<wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
