From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 16:49:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A86E5F1; Tue, 9 Jul 2013 16:49:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 580411CA7; Tue, 9 Jul 2013 16:49:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CC244B94A; Tue, 9 Jul 2013 12:49:42 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Ipfilter pre-Vendor Import Issue Date: Tue, 9 Jul 2013 12:49:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307082000.r68K02Ef063517@slippy.cwsent.com> <20130709092136.GL67810@glebius.int.ru> In-Reply-To: <20130709092136.GL67810@glebius.int.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307091249.36403.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Jul 2013 12:49:42 -0400 (EDT) Cc: Gleb Smirnoff , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:49:43 -0000 On Tuesday, July 09, 2013 5:21:36 am Gleb Smirnoff wrote: > On Mon, Jul 08, 2013 at 01:00:02PM -0700, Cy Schubert wrote: > C> > The BSD license allows us to put the code into FreeBSD w/o any separation. > C> > > C> > So the question is: what is more handy to us? > C> > > C> > What do we actually gain having contrib/ipf, assuming we got vendor branch > C> > already? > C> > > C> > What we lose is: > C> > - more complex Makefiles > C> > - more complex hacking: edit files in one place, run make in other > C> > C> How is this for a plan? > C> > C> Instead of importing the kernel bits into vendor-sys/ipfilter and the > C> userland bits into vendor/ipfilter, the base tarball should be imported > C> into vendor-sys/ipfilter (or vendor/ipfilter, doesn't matter which). We > C> keep the complete tarball imported into one place in the tree. > > I'd prefer vendor/ipfilter as single place of vendor imports. > > C> Merge ipfilter into sys/netpfil/ipfilter (for kernel bits) and > C> netpfil/ipfilter (for userland bits). > C> > C> We should probably think of moving pf and ipfw into the new subdirectory as > C> well, but that's for a future discussion. > > No, userland tools should be placed in bin|sbin|usr.bin|usr.sbin, > according to the place where they are installed. An exlusion can be made > adding a intermediate subdir (like this is already done for ipfilter tools), > to group all related tools together. Please, please! Let's not make ipfilter some random one-off vendor source that imports code into random places. The remaining instances of that that we have (such as stdtime) are a PITA to deal with. vendor/ipfilter == userland bits => contrib/ipfilter. You then put suitable Makefiles/build glue that uses .PATH in usr.bin|sbin|whatever. vendor-sys/ipfilter == kernel bits => sys/contrib/ipfilter. You then fix sys/conf/files, etc. as appropriate. This is our _standard_ practice for dealing with this stuff. This is how all the OpenSolaris bits for Dtrace and ZFS are handled (except that they end up in a cddl directory instead of contrib). GENERIC / LINT builds can include things from sys/contrib just fine, so ipfilter won't be missed by builds, etc. -- John Baldwin