From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 15:58:59 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CCB16A418 for ; Sun, 2 Dec 2007 15:58:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A98FE13C447 for ; Sun, 2 Dec 2007 15:58:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 73DA217105; Sun, 2 Dec 2007 15:58:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id lB2FwwLP019723; Sun, 2 Dec 2007 15:58:58 GMT (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 02 Dec 2007 08:46:48 MST." <20071202.084648.-108809549.imp@bsdimp.com> Date: Sun, 02 Dec 2007 15:58:58 +0000 Message-ID: <19722.1196611138@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: New "timeout" api, to replace callout 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: Sun, 02 Dec 2007 15:59:00 -0000 In message <20071202.084648.-108809549.imp@bsdimp.com>, "M. Warner Losh" writes : >In message: <15391.1196547545@critter.freebsd.dk> > Poul-Henning Kamp writes: >>>/* >>> * A duration of time, represented in the optimal way for a given provider >>> * or family of providers (ie: per cpu). >>> */ >>>typedef int timeout_time; > >What does this mean? How do I get one of those? Without a unit >associated with this number, it becomes hard to do a "tickless" >implementation. You get it back from the timeout provider. The point here is that most timeout clients use the same time interval again and again, so precalculating any "magic" values for the specific hardware makes sense. In practice your code could look like: struct foo_softc { timeout_time timeout_duration; }; ... foo_attach() { [...] sc->timeout_duration = timeout_conv_time([...], 200, TIMEOUT_MSEC); } foo_something() { timeout_arm(sc->timeout, sc->timeout_duration, [flags]); } -- 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.