Date: Thu, 13 Sep 2012 23:31:25 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: luigi@FreeBSD.org, "Bjoern A. Zeeb" <bz@FreeBSD.org>, net@FreeBSD.org Subject: Re: moving pfil consumers to sys/netpfil Message-ID: <20120913193125.GO85604@glebius.int.ru> In-Reply-To: <20120913174105.GA22571@onelab2.iet.unipi.it> References: <20120912123457.GC85604@glebius.int.ru> <20120912211726.GB10974@onelab2.iet.unipi.it> <alpine.BSF.2.00.1209131623350.13080@ai.fobar.qr> <20120913174105.GA22571@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120913193125.GO85604>