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:
signature.asc
Description: OpenPGP digital signature
