From owner-freebsd-arch@FreeBSD.ORG  Tue Jan 27 10:11:08 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6701816A4CE
	for <arch@freebsd.org>; Tue, 27 Jan 2004 10:11:08 -0800 (PST)
Received: from relay.pair.com (relay.pair.com [209.68.1.20])
	by mx1.FreeBSD.org (Postfix) with SMTP id A15B943D55
	for <arch@freebsd.org>; Tue, 27 Jan 2004 10:11:05 -0800 (PST)
	(envelope-from silby@silby.com)
Received: (qmail 29788 invoked from network); 27 Jan 2004 18:10:38 -0000
Received: from niwun.pair.com (HELO localhost) (209.68.2.70)
  by relay.pair.com with SMTP; 27 Jan 2004 18:10:38 -0000
X-pair-Authenticated: 209.68.2.70
Date: Tue, 27 Jan 2004 12:10:36 -0600 (CST)
From: Mike Silbersack <silby@silby.com>
To: Bruce Evans <bde@zeta.org.au>
In-Reply-To: <20040126212725.E1244@gamplex.bde.org>
Message-ID: <20040127120826.V4636@odysseus.silby.com>
References: <20040125230314.S730@odysseus.silby.com>
	<20040126212725.E1244@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: arch@freebsd.org
Subject: Re: Updating callout_reset
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jan 2004 18:11:08 -0000



On Mon, 26 Jan 2004, Bruce Evans wrote:

> Many callers don't worry much about efficiency and do calculations like
> (hz / 10) to get the timeout.  This is still more efficient than the
> 64-bit divisions and other complications needed to handle general
> conversions of times to timeouts.  (Look at tvtohz().  Note that the
> complications in it have very little to do with struct timeval not
> being a scalar type.  They are to handle representation problems.)
>
> Bruce

I've thought more about this, and although I could debate some points,
you've convinced me that changing the interface without changing the
implementation is totally pointless.  So, if I ever get around to
implementation changes, then I'll come back and we can rediscuss some
of these issues.

Mike "Silby" Silbersack