docs: move some of them to the root directory

Lets move CodingStyle, SubmittingPatches, and Sponsors into the
root directory of netsniff-ng and remove the Documentation folder.
Some of those files are quite bloated, and most of these things
should be in the man-pages anyway. They should be the only big
sources of documentation, nothing else.

The rest is currently put here: http://pub.netsniff-ng.org/docs/

Signed-off-by: Daniel Borkmann <dborkman@redhat.com>

1 files changed, 0 insertions, 87 deletions

diff --git a/Documentation/RelatedWork b/Documentation/RelatedWork
deleted file mode 100644
index ed7dba8..0000000
--- a/Documentation/RelatedWork
+++ /dev/null
@@ -1,87 +0,0 @@
-Work that relates to netsniff-ng and how we differ from it:
-///////////////////////////////////////////////////////////
-
-ntop
- * W: http://www.ntop.org/
-
- The ntop projects offers zero-copy for network packets. Is this approach
- significantly different from the already built-in from the Linux kernel?
- High likely not. In both cases packets are memory mapped between both address
- spaces. The biggest difference is that you get this for free, without
- modifying your kernel with netsniff-ng since it uses the kernel's RX_RING
- and TX_RING functionality. Unfortunately this is not really mentioned on the
- ntop's website. Surely for promotional reasons. For many years the ntop
- projects lives on next to the Linux kernel, attempts have been made to
- integrate it [1] but discussions got stuck and both sides seem to have no
- interest in it anymore, e.g. [2]. Therefore, if you want to use ntop, you are
- dependent on ntop's modified drivers that are maintained out of the Linux
- kernel's mainline tree. Thus, this will not provide you with the latest
- improvements. Also, the Linux kernel's PF_PACKET is maintained by a much bigger
- audience, probably better reviewed and optimized. Therefore, also we decided
- to go with the Linux kernel's variant. So to keep it short: both approaches
- are zero-copy, both have similar performance (if someone tells you something
- different, he would lie due to their technical similarities) and we are using
- the kernel's built-in variant to reach a broader audience.
-
- [1] http://lists.openwall.net/netdev/2009/10/14/37
- [2] http://www.spinics.net/lists/netfilter-devel/msg20212.html
-
-tcpdump
- * W: http://www.tcpdump.org/
-
- tcpdump is probably the oldest and most famous packet analyzer. It is based on
- libpcap and in fact the MIT team that maintains tcpdump also maintains libpcap.
- It has been ported to much more architectures and operating systems than
- netsniff-ng. However, we don't aim to rebuild or clone tcpdump. We rather focus
- on achieving a higher capturing speed by carefully tuning and optimizing our
- code. That said doesn't mean that tcpdump people do not take care of it. It
- just means that we don't have additional layers of abstractions for being as
- portable as possible. This already gives us a smaller code footprint. Also, on
- default we perform some system tuning such as remapping the NIC's IRQ affinity
- that tcpdump probably would never do due to its generic nature. By generic, we
- mean to serve as many different user groups as possible. We rather aim at
- serving users for high-speed needs. By that, they have less manual work to do
- since it's already performed in the background. Next to this, we also aim at
- being a useful networking toolkit rather than only an analyzer. So many other
- tools are provided such as trafgen for traffic generation.
-
-Wireshark/tshark
- * W: http://www.wireshark.org/
-
- Probably we could tell you the same as in the previous section. I guess it is
- safe to say that Wireshark might have the best protocol dissector out there.
- However, this is not a free lunch. You pay for it with a performance
- degradation, which is quite expensive. It is also based on libpcap (we are not)
- and it comes with a graphical user interface, whereas we rather aim at being
- used somewhere on a server or middle-box site where you only have access to a
- shell, for instance. Again, offline analysis of /large/ pcap files might even
- let it hang for a long time. Here netsniff-ng has a better performance also in
- capturing pcaps. Again, we furthermore aim at being a toolkit rather than only
- an analyzer.
-
-libpcap
- * W: http://www.tcpdump.org/
-
- Price question: why don't you rely on libpcap? The answer is quite simple. We
- started developing netsniff-ng with its zero-copy capabilities back in 2009
- when libpcap was still doing packet copies between address spaces. Since the
- API to the Linux kernel was quite simple, we felt more comfortable using it
- directly and bypassing this additional layer of libpcap code. Today we feel
- good about this decision, because since the TX_RING functionality was added to
- the Linux kernel we have a clean integration of both, RX_RING and TX_RING.
- libpcap on the other hand was designed for capturing and not for transmission
- of network packets. Therefore, it only uses RX_RING on systems where it's
- available but no TX_RING functionality. This would have resulted in a mess in
- our code. Additionally, with netsniff-ng, one is able to a more fine grained
- tuning of those rings. Why didn't you wrap netsniff-ng around your own library
- just like tcpdump and libpcap? Because we are ignorant. If you design a library
- than you have to design it well right at the beginning. A library would be a
- crappy one if it changes its API ever. Or, if it changes its API, than it has
- to keep its old one for the sake of being backwards compatible. Otherwise no
- trust in its user or developer base can be achieved. Further, by keeping this
- long tail of deprecated functions you will become a code bloat over time. We
- wanted to keep this freedom of large-scale refactoring our code and not having
- to maintain a stable API to the outer world. This is the whole story behind it.
- If you desperately need our internal functionality, you still can feel free to
- copy our code as long as your derived code complies with the GPL version 2.0.
- So no need to whine. ;-)