From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 19:31:33 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72CEF106566B; Thu, 13 Sep 2012 19:31:33 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id E557C8FC08; Thu, 13 Sep 2012 19:31:32 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q8DJVPin097971; Thu, 13 Sep 2012 23:31:25 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q8DJVPJN097970; Thu, 13 Sep 2012 23:31:25 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 13 Sep 2012 23:31:25 +0400 From: Gleb Smirnoff To: Luigi Rizzo Message-ID: <20120913193125.GO85604@glebius.int.ru> References: <20120912123457.GC85604@glebius.int.ru> <20120912211726.GB10974@onelab2.iet.unipi.it> <20120913174105.GA22571@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20120913174105.GA22571@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: luigi@FreeBSD.org, "Bjoern A. Zeeb" , net@FreeBSD.org Subject: Re: moving pfil consumers to sys/netpfil X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 19:31:33 -0000 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.