From owner-freebsd-pf@FreeBSD.ORG Tue Jul 10 06:19:57 2007 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B36CD16A400 for ; Tue, 10 Jul 2007 06:19:57 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 60DF513C457 for ; Tue, 10 Jul 2007 06:19:57 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=G9D2WuWdJdgvtWLLrDpggzUpfJEeeVSgErIVJW0lKhwy0kEvjNS7NjFk8Xi3/UuPEJr0IZXwalo1UR39XkMrFmICE/QUyNRCyiY8ifIQWPSLb9bX1D/VdLM0ZAAKXo85KHEZwMLAwtBdR018dc+cUBKEOkpDaaYZVuGVZ2xrUd8=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1I894k-0007SL-UZ; Tue, 10 Jul 2007 10:19:55 +0400 Date: Tue, 10 Jul 2007 10:19:50 +0400 From: Eygene Ryabinkin To: Nate Lawson Message-ID: <20070710061950.GB38151@void.codelabs.ru> References: <200706160347.33331.max@love2party.net> <20070617094126.GT3779@void.codelabs.ru> <200706171717.21585.max@love2party.net> <20070619074150.GC26920@void.codelabs.ru> <4677FF00.4060506@root.org> <20070620152609.GD26920@void.codelabs.ru> <20070620190423.GH26920@void.codelabs.ru> <468ACC91.9010806@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <468ACC91.9010806@root.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-pf@freebsd.org Subject: Re: pf 4.1 Update available for testing X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 06:19:57 -0000 Nate, good day. Tue, Jul 03, 2007 at 03:24:17PM -0700, Nate Lawson wrote: > I have tried to achieve the same goal with a simpler patch. Here are > the changes: > > Be sure to initialize the callout struct and other setup tasks before > proceeding. Previously, machclk_freq could be set to a non-zero value > by tsc_freq_changed(), preventing the callout from being initialized. > To fix this, call init_machclk() from all paths. init_machclk() is > split into two functions, one that only runs the first time it is > called. The second half runs each time the frequency changes and > calibrates various items. Also, static variables are zero so no need to > initialize them. > > If you can test this, that would be great. Yes, it seems to work. I am a little concerned with the dependency your patch introduces: it assumes that init_machclk() will always use tsc_freq as the frequency source. So one day when another counter will appear one will need to locate all respective references to the tsc_freq and change them accordingly. That was the reason for my lengthy changes: the explicit API. May be the simple comment around init_machclk() will be enough, but explicit parameter will be better. I will try to think how it can be done with your patch, but if any of you have some thoughts why it shouldn't be done this way or have some other ideas -- I am all ears. Thank you! -- Eygene