moving pfil consumers to sys/netpfil

[Gleb Smirnoff]

On Thu, Sep 13, 2012 at 07:41:05PM +0200, Luigi Rizzo wrote:
L> Second:
L>    What i contest is the fact that you classify ipfw as a "pfil client",
L>    when pfil is just a tiny adaptation layer to access ipfw.
L>    I mentioned the three alternative APIs (netmap, netfilter, ndis)
L>    to witness the fact that pfil is irrelevant to ipfw's operation.

In FreeBSD ipfw is a pfil client. Dot.

In Linux it is netfilter client, and if they want to they may or may not
put it under netfilter/ipfw. We don't care. Same for Windows and ndis.

ipfw isn't netinet specific, it also supports netinet6 and also supports
layer2 pfil hooks.

Putting all pfil clients into one place puts things in order. It simplifies
kernel overview for newcomer, it makes things easier for those who want
to hack on the pfil itself.

L> Third:
L>    any code relocation comes with some pain -- specifically, netinet/
L>    is hardwired in many #include paths in the ipfw sources
L> 
L> 	> grep netinet/ipfw sys/netinet/ipfw/* | grep include | wc
L> 	      35      70    1791

Numbers from your grep are impressive, but they are absolutely irrelevant.
Actual diff for movement isn't that big. For example:

- sys/net has zero diff, no files modified
- sys/netinet/* has zero diff, just ipfw directory removed, no files modified
- sbin/ipfw has zero diff

This is actual diff that is already universe-tested.

L>    so having it relocated (and in different places between HEAD and
L>    STABLE/9, and other platforms that may not count for you but do
L>    count for the maintainer, aka me) causes some extra maintainance
L>    work which I am willing to take if there are good reasons,
L>    but i do not see now.


-- 
Totus tuus, Glebius.