From owner-freebsd-arch@FreeBSD.ORG Thu Nov 30 06:59:45 2006 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 CBD7A16A4A0; Thu, 30 Nov 2006 06:59:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12A5C43CA5; Thu, 30 Nov 2006 06:59:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kAU6uqAY026779; Wed, 29 Nov 2006 23:56:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 29 Nov 2006 23:57:41 -0700 (MST) Message-Id: <20061129.235741.-278387249.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <13587.1164869601@critter.freebsd.dk> References: <20061129.234811.-1625879484.imp@bsdimp.com> <13587.1164869601@critter.freebsd.dk> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 29 Nov 2006 23:56:53 -0700 (MST) Cc: rwatson@freebsd.org, freebsd-arch@freebsd.org Subject: Re: a proposed callout API 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: Thu, 30 Nov 2006 06:59:45 -0000 In message: <13587.1164869601@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20061129.234811.-1625879484.imp@bsdimp.com>, "M. Warner Losh" write : s: : : >I'd also argue that UTC is just a printing convention anyway. Keeping : >time in a TAI-like timescale and doing the conversion to UTC when UTC : >timestamps are necessary would be worth considering, but there are : >some costs with doing this that might prove to be too high since UTC : >is used a lot and any TAI-like thing is only used for the 'core' : >timing stuff. : : As far as I know we have no sleepers on UTC scale in the kernel and : nobody has said otherwise throughout this discussion. Then never mind, that solve that problem :-) Warner