From owner-cvs-src@FreeBSD.ORG Wed May 24 21:11:54 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D97D016A946; Wed, 24 May 2006 21:11:53 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EA9643D6B; Wed, 24 May 2006 21:11:49 +0000 (GMT) (envelope-from vadimnuclight@tpu.ru) Received: by relay1.tpu.ru (Postfix, from userid 501) id C888610C84A; Thu, 25 May 2006 04:11:46 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 69FC610C841; Thu, 25 May 2006 04:11:46 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 04:11:46 +0700 Received: from nuclight.avtf.net ([82.117.64.107]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 04:11:45 +0700 Date: Thu, 25 May 2006 04:10:15 +0700 To: cvs-src@freebsd.org References: <200605241309.k4OD9tex003002@repoman.freebsd.org> <44747A4C.9090800@freebsd.org> <44748DF8.000002.11682@camay.yandex.ru> <4474C17A.10604@freebsd.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4474C17A.10604@freebsd.org> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 24 May 2006 21:11:45.0804 (UTC) FILETIME=[A9C92CC0:01C67F76] Cc: src-committers@freebsd.org, oleg@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/netinet ip_fw.h ip_fw2.c src/sbin/ipfw ipfw.8 ipfw2.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 21:12:06 -0000 25.05.06 @ 03:26 Andre Oppermann wrote: >>> Does this accept the packet and untag it at the same time? Wouldn't >>> it make more sense to have [tag|untag] as its own operators like >>> [allow|deny]? >> Yes, it does (but example is impractical - we don't need tagging or >> untagging when packet is finally denied). We thought about making >> [tag|untag] as its own actions like [allow|deny], but decided to >> implement it as modifiers instead, for two primary reasons: >> 1) Speed. It is faster to match packet with body of only one rule than >> to do it once more for the same packet in the next rule, only to take >> action on it. >> 2) Flexibility. We can use modifiers tag/untag with any possible >> actions, e.g. allow, netgraph, skipto, pipe, ... - not only >> [allow|deny]. Imagine you have to insert additional tagging rule for >> any such action looking absolutely the same? And then consider speed of >> matching. Thus, it is even *looks* more beautiful to write: >> ipfw add 100 netgraph 300 tag 200 ip from host1 to host2 >> for tagging packet with tag 200 and then sending it to netgraph, than >> to write something like: >> ipfw add 100 tag 200 ip from host1 to host2 >> ipfw add 101 netgraph 300 ip from host1 to host2 tagged 200 Sorry, "tagged 200" is unnecessary there (or one can imagine, e.g. "tagged 400" on both rules - tagging already tagged by another tag). > I understand your rationale. OTOH I think it's a logical blunder and > allows > some quite confusing rule sets. What I always liked about ipfw was the > simple Umm, perhaps it should be documented more clearly in man page?.. > and obvious logic in the statements. Over time it becomes more and more > over- > loaded with more stuff and also more stuff breaking the beautiful > simplicity > and clarity the original ipfw design had. ipfw rules used to read like > normal > sentences and were really simple to write and understand. But then I'm > just ranting... Yes, I'll agree about beautiful clear syntax of ipfw, I also like it very much. But it is still clear when all that new overloading features are not used > To be honest I would prefer to fix the rule evaluation performance > problem of ipfw rather than to clutter the original beautiful rule syntax > logic. Another $0.02 about logic - altq in ipfw also does its work in addition to main action instead of separate action keyword. Tag functionality in pf (from which idea and keywords are borrowed) also made as addition, not separate action. So IMHO these ipfw tags follow the same unified style. -- WBR, Vadim Goncharov