From owner-freebsd-arch@FreeBSD.ORG Wed Feb 28 02:24:00 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D10416C72E for ; Wed, 28 Feb 2007 02:24:00 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 04D2F13C428 for ; Wed, 28 Feb 2007 02:23:59 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 81904 invoked from network); 28 Feb 2007 00:42:05 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 28 Feb 2007 00:42:05 -0000 Message-ID: <45E4CFE8.6090509@root.org> Date: Tue, 27 Feb 2007 16:42:16 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Max Laier References: <45E4ADCD.4090909@root.org> <200702280119.08987.max@love2party.net> In-Reply-To: <200702280119.08987.max@love2party.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: PATCH - update TSC freq when cpufreq changes it X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 02:24:00 -0000 Max Laier wrote: > On Tuesday 27 February 2007 23:16, Nate Lawson wrote: >> Attached is a patch that uses eventhandlers to update the TSC freq. >> This is important because DELAY() uses TSC directly (on i386 and amd64) >> but the rate calculated at boot changes if cpufreq is in use. >> >> It maintains current behavior that cpufreq transitions are denied if >> TSC is the active timecounter. The API is that there is a pre and post >> transition eventhandler that is called by the cpufreq core. The pre >> handler is passed the next state (including freq, power, etc.) and can >> store a non-zero status value in the output arg to indicate it wants to >> reject the transition. The post handler also is passed the next state >> and the result of the transition (0 on success). > > Any reason for passing the result to the post handler in by reference - > other than being able to re-use the same function type as in the pre > handler? API-wise this seems to be a mistake as one consumer could mess > up the result for the rest and the variable name "error" in the INVOKE > also suggests that this could be used to report back. Yes, the main gaol was to reuse the function. Plus I thought in the future there might be some conceivable need to revoke a change after it had occurred ("oops! change right back!"). We wouldn't need to change an API to allow that. Unless there's a real problem with it, I'd like to keep that ability in the API. To make it clear though, I should probably assign error to some tmp var and pass that in to cpufreq_post_change handlers so it has no effect if the user overwrites it. -- Nate