From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 29 15:38:56 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC4A11065671 for ; Fri, 29 Feb 2008 15:38:56 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id 778248FC27 for ; Fri, 29 Feb 2008 15:38:56 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-62-10-20-127.cust-adsl.tiscali.it [62.10.20.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id A736411AE8D; Fri, 29 Feb 2008 16:38:51 +0100 (CET) Received: (from piso@localhost) by southcross.wired.org (8.14.2/8.14.1/Submit) id m1TFfjtx007039; Fri, 29 Feb 2008 16:41:45 +0100 (CET) (envelope-from piso) Date: Fri, 29 Feb 2008 16:41:44 +0100 From: piso@FreeBSD.org To: Vadim Goncharov Message-ID: <20080229154144.GA81243@tin.it> References: <20080228151134.GA73358@tin.it> <20080229095150.GA76592@tin.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: freebsd-ipfw@FreeBSD.org Subject: Re: [patch] ipfw_nat as a kld module X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 15:38:56 -0000 On Fri, Feb 29, 2008 at 02:37:14PM +0000, Vadim Goncharov wrote: > >> * struct ip_fw_chain moved to .h and no longer static, is this good? > >> I suggest to move into it's own static chain in module, see next > > the symbol is used outside it's originating file > > Is it needed if LIST_HEAD will be in its own module? every modification/access to layer3_chain lock is arbitrated via its own rwlock(), thus to answer your question, yes, there are places where we would need access to layer3_chain > > that's something i thought about, but i didn't see any tangible improvement > > to this modification, cause part of ipfw_nat would still be called from > > ipfw2.c (see ipfw_ctl). > > This could be fixed, too, as is done with dummynet, which is also configured > via ipfw(8). As it is HEAD, ABI can be broken and this will not be done via > ipfw_ctl(). yes, but does it buy us anything? moreover, we would loose the ability to merge the work back to 7.x. bye, P.