From owner-freebsd-current@FreeBSD.ORG Tue Jun 22 11:45:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2007B16A4CF for ; Tue, 22 Jun 2004 11:45:37 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E68043D39 for ; Tue, 22 Jun 2004 11:45:36 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 70532 invoked from network); 22 Jun 2004 11:45:35 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Jun 2004 11:45:35 -0000 Message-ID: <40D81BE4.B82F01A3@freebsd.org> Date: Tue, 22 Jun 2004 13:45:40 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Konovalov References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> <20040622133000.T6489@mp2.macomnet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: freebsd-current@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Jun 2004 11:45:37 -0000 Maxim Konovalov wrote: > > On Tue, 22 Jun 2004, 02:06-0700, Luigi Rizzo wrote: > > > On Tue, Jun 22, 2004 at 12:15:21PM +0400, Maxim Konovalov wrote: > > ... > > > > Consider this a FYI. It is very much a WIP at the moment. I want > > > > to get this into the tree in before 5.3 code freeze. > > > > > > In fact, our real world tests shown the current -CURRENT comparing to > > > RELENG_5_2 is in a very bad shape. Is it really worth to commit that > > > mostly cleanup code before say 6-CURRENT with a chance to > > > > of course it is! i also do not follow the reasoning -- given that it is > > cleaning up code, it is only welcome at any stage except perhaps > > in code freeze. > > My concern is bugs. Especially in cleanup code, especially in > ip_pcbopt and ip_reass. I do not modify ip_pcbopt in any way. All the IP Options stuff is simply a 1:1 code move to get them all in one single place. For ip_reass() I've taken a very conservative approach and just moved the external code into the function itself. In terms of coding style it looks a bit ugly but is a pure 1:1 adaption of the existing code. Thus I'm sure that I haven't changed the behaviour of the ip reassembly code in any way (except one). I agree that a rewrite of ip_reass() is a very delicate thing because of possible bugs, but that is not what I have done. -- Andre