From owner-freebsd-arch@FreeBSD.ORG Tue Dec 18 23:44:00 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 1E482243; Tue, 18 Dec 2012 23:44:00 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C1D398FC0C; Tue, 18 Dec 2012 23:43:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 073547300A; Wed, 19 Dec 2012 00:42:41 +0100 (CET) Date: Wed, 19 Dec 2012 00:42:41 +0100 From: Luigi Rizzo To: Ian Lepore Subject: Re: API explosion (Re: [RFC/RFT] calloutng) Message-ID: <20121218234240.GA97678@onelab2.iet.unipi.it> 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> <20121218232955.GA97440@onelab2.iet.unipi.it> <1355873830.1198.189.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1355873830.1198.189.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Alexander Motin , 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: Tue, 18 Dec 2012 23:44:00 -0000 On Tue, Dec 18, 2012 at 04:37:10PM -0700, Ian Lepore wrote: > On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote: > > On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote: > > > On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: > > > > [top posting for readability; > > > > in summary we were discussing the new callout API trying to avoid > > > > an explosion of methods and arguments while at the same time > > > > supporting the old API and the new one] > > > > (I am also Cc-ing phk as he might have better insight > > > > on the topic). > > > > > > > > I think the patch you propose is a step in the right direction, > > > > but i still remain concerned by having to pass two bintimes > > > > (by reference, but they should really go by value) > > > > and one 'ticks' value to all these functions. > > > > > > > > I am also dubious that we need a full 128 bits to specify > > > > the 'precision': there would be absolutely no loss of functionality > > > > if we decided to specify the precision in powers of 2, so a precision > > > > 'k' (signed) means 2^k seconds. This way 8 bits are enough to > > > > represent any precision we want. > > > > ... > > > I'm not so sure about the 2^k precision. You speak of seconds, but I > > > would be worrying about sub-second precision in my work. It would > > > typical to want a 500uS timeout but be willing to late by up to 250uS if > > > > i said k is signed so negative values represent fractions of a > > second. 2^-128 is pretty short :) > > > > cheers > > luigi > > Ahh, I missed that. Good enough then! Hmmm, if that ideas survives > further review, then could precision be encoded in 8 bits of the flags, > eliminating another parm? that was also what i wrote later in the message :) now we should figure out some use for the remaining 22 bits of the flags cheers luigi