From owner-freebsd-arch@FreeBSD.ORG Wed Dec 19 11:00:09 2012 Return-Path: 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 0C515955; Wed, 19 Dec 2012 11:00:09 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id AB49B8FC1E; Wed, 19 Dec 2012 11:00:08 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 812708A512; Wed, 19 Dec 2012 11:00:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBJB06xL015948; Wed, 19 Dec 2012 11:00:06 GMT (envelope-from phk@phk.freebsd.dk) To: Alexander Motin Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-reply-to: <50D192E8.3020704@FreeBSD.org> From: "Poul-Henning Kamp" References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <50D192E8.3020704@FreeBSD.org> Date: Wed, 19 Dec 2012 11:00:06 +0000 Message-ID: <15947.1355914806@critter.freebsd.dk> Cc: Davide Italiano , Ian Lepore , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 11:00:09 -0000 -------- In message <50D192E8.3020704@FreeBSD.org>, Alexander Motin writes: >Linux uses 32.32 format in their eventtimers code. (And that is no accident, I know who they got the number from :-) >But if at some point we want to be able to >handle absolute wall time, [...] Then you have other problems, including but not limited to clock being stepped, leap-seconds, suspend/resume and frequency stability. If you want to support callouts of the type ("At 14:00 UTC tomorrow") (disregarding the time-zone issue), you need to catch all significant changes to our UTC estimate and recalibrate your callout based on that. It is not obvious that we have applications for such an API that warrant the complexity. Either way, such a facility should be layered on top of the callout facility, which should always run in "elapsed time"[1] with no attention paid to what NTPD might do to the UTC estimate. So summary: 32.32 is the right format. Poul-Henning [1] Notice that "elapsed time" needs a firm definition with respect to suspend/resume, and that this decision has big implications for the API use and code duplication. I think it prudent to specify a flag to callouts, to tell what should happen on suspend/resume, something like: SR_CANCEL /* Cancel the callout on S/R */ /* no flag* /* Toll this callout only when system is running */ SR_IGNORE /* Toll suspended time from callout */ If you get this right, callouts from device drivers will just "DTRT", if you get it wrong, all device drivers will need boilerplate code to handle S/R -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.