From owner-freebsd-ipfw@FreeBSD.ORG Tue Jul 15 12:11:52 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36D7237B439 for ; Tue, 15 Jul 2003 12:11:52 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC35E43F75 for ; Tue, 15 Jul 2003 12:11:51 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h6FJBmkN003210; Tue, 15 Jul 2003 12:11:48 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h6FJBmsI003209; Tue, 15 Jul 2003 12:11:48 -0700 (PDT) (envelope-from rizzo) Date: Tue, 15 Jul 2003 12:11:48 -0700 From: Luigi Rizzo To: Diego Linke - GAMK Message-ID: <20030715121148.A2668@xorpc.icir.org> References: <3F132237.4010604@freebsdbrasil.com.br> <20030715004113.A99565@xorpc.icir.org> <20030715120646.03f26167.linke@calnet.com.br> <20030715101516.A87982@xorpc.icir.org> <20030715151042.698b355a.linke@calnet.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030715151042.698b355a.linke@calnet.com.br>; from linke@calnet.com.br on Tue, Jul 15, 2003 at 03:10:42PM -0300 cc: freebsd-ipfw@freebsd.org Subject: Re: I have four ideia for IPFW2 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 19:11:53 -0000 On Tue, Jul 15, 2003 at 03:10:42PM -0300, Diego Linke - GAMK wrote: > Hi, > > > you can use spare fields in ipfw_insn o; for that > > You dont want us to change ip_fw.h, or you only mean that ipfw_insn_log struct should not be modified? > > Maybe a new struct could be created, say, ipfw_insn_log_ext, or touching the .h would brake the POLA? There is spare storage in ipfw_insn (the arg1 field) which can be used by individual instructions to store flags and other data if they fit. The 'extended' flag for log instructions would certainly fit there, and would make the change completely backward compatible, which is a big advantage from every point of view. cheers luigi