From owner-freebsd-arch@FreeBSD.ORG Thu Nov 30 06:47: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 8330416A407; Thu, 30 Nov 2006 06:47: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 E3F2C43C9D; Thu, 30 Nov 2006 06:47: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 kAU6lN33026637; Wed, 29 Nov 2006 23:47:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 29 Nov 2006 23:48:11 -0700 (MST) Message-Id: <20061129.234811.-1625879484.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <11587.1164837604@critter.freebsd.dk> References: <200611291650.51782.jhb@freebsd.org> <11587.1164837604@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:47:24 -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:47:45 -0000 In message: <11587.1164837604@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <200611291650.51782.jhb@freebsd.org>, John Baldwin writes: : : >> I want it marked up directly in the flags passed which kind of behaviour : >> the code wants. : > : >Hmm, I guess that depends on what you consider tick_t to be. I was thinking : >of it as an abstract type for a deadline, and that absolute and relative are : >sort of like subclasses of that. : : I see tick_t only as an opaque measure of time and would prefer to : not have modal bits stuck into it because I fear that will make it : larger than 32 bits. There's many times and places that confuse a time interval with an elapsed time since an epoch. struct timeval started life as the latter and was press-ganged to also surve as the former. Having different types allows for an unabiguous conversion. I don't believe there's a prohibitive cost in doing this. 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. Warner