All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christoph A." <casmls@gmail.com>
To: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
Cc: "Christoph A." <casmls@gmail.com>
Subject: codesize: netfilter/iptables vs. nftables
Date: Tue, 11 Aug 2009 12:24:04 +0200	[thread overview]
Message-ID: <4A8146C4.5090108@gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

Hi,

from my understanding of the initial announcement of nftables [1]

unlike the iptables kernel approach, nftables does not have a 1-to-1
mapping of matches with modules in the kernel and provides only basic
functionality/operations, userspace can use to combine to build
matches/rules. (intelligence moves from kernel to userspace)

[1]
http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/28922

When creating new matches/targets in iptables one must create the
appropriate ipt/xt_<match> module for the kernel plus the userspace
module  libipt/libxt_<match>.

With the generic way in which a nftables kernel handles data / provides
functions I would assume that this approach of supporting new matches
would change, and one must only create new combinations of kernel
provided operations which does not require kernel code modifications.
The kernelcode size of nftables would be constant regardless of how many
matches it supports.
Is this assumption correct?

Another thing I would like to know is the current codesize of
netfilter/iptables (including ip6tables and ebtables modules) compared
to nftables kernelsize (sloc) (although the current featureset may defer)


I compared them like this:

1. step:
count lines with sloccount in the following directories:
net/ipv4/netfilter/
net/ipv6/netfilter/
net/bridge/netfilter/
net/netfilter/

(gives me 802 files and 62462 SLOC)

2. step:
count lines in the same directories but only including files starting
with nft_*

(62 files and 2288 SLOC)

3. step:
subtraction:
sloc_step1
sloc_step2
(62462 - 2288 = 60174)

netfilter/iptables: 60174 SLOC
only nft_ files: 2288 SLOC
(using nft-2.6 87f619abc27c38583abbf7268319c3f105bf09fd)

this is only correct if nftables does not depend on any code already
present in non nft_* files and I guess this is not correct...(?)

thanks in advance
Christoph A.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

             reply	other threads:[~2009-08-11 12:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-11 10:24 Christoph A. [this message]
2009-08-11 13:53 ` codesize: netfilter/iptables vs. nftables Patrick McHardy
2009-08-12 14:32   ` Christoph A.
2009-08-11 16:53 ` Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A8146C4.5090108@gmail.com \
    --to=casmls@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.