From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 20:37:43 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 0F9E5106564A; Thu, 13 Sep 2012 20:37:43 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BD4468FC0C; Thu, 13 Sep 2012 20:37:42 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 03E237300A; Thu, 13 Sep 2012 22:57:22 +0200 (CEST) Date: Thu, 13 Sep 2012 22:57:21 +0200 From: Luigi Rizzo To: Gleb Smirnoff Message-ID: <20120913205721.GA24570@onelab2.iet.unipi.it> References: <20120912123457.GC85604@glebius.int.ru> <20120912211726.GB10974@onelab2.iet.unipi.it> <20120913174105.GA22571@onelab2.iet.unipi.it> <20120913193125.GO85604@glebius.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120913193125.GO85604@glebius.int.ru> User-Agent: Mutt/1.4.2.3i 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 20:37:43 -0000 On Thu, Sep 13, 2012 at 11:31:25PM +0400, Gleb Smirnoff wrote: > 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. This is the second time a "we don't care" statement appears in this discussion and I find them extremely non constructive. I do not know who you consider as "we", but as one who maintains the code under multiple platforms i do have an interest in avoiding gratuitous changes that introduce differences between the various versions. > 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 please remain in context. We were talking about the files in netinet/ipfw, which have #include in them, so when moved to the new location these 35 lines need to be changed to #include Which is completely trivial, but introduces a difference between the files in HEAD and those in stable/9 (and in the other versions "we don't care" about) . Now if your plan involves removing the netinet/ prefix and adding ... compile-with "${NORMAL_C} -I$S/netpfil" to the lines in HEAD:sys/conf/files, and ... compile-with "${NORMAL_C} -I$S/netinet" for those in stable/9, i can lift this objection. I still think that a subsystem should not be classified by looking at one of the APIs it uses, but rather based on overall functionality. Hence in my opinion ipfw does not belong under netpfil/ more than it belongs under netinet/ , and lacking a better place i consider the relocation a gratuitous one. > This is actual diff that is already universe-tested. (attachment probably stripped by the mailing list ?) cheers luigi