From owner-freebsd-arch@FreeBSD.ORG Sat Nov 10 14:05:16 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E636116A420 for ; Sat, 10 Nov 2007 14:05:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188]) by mx1.freebsd.org (Postfix) with ESMTP id F33F513C48D for ; Sat, 10 Nov 2007 14:05:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so964916mue for ; Sat, 10 Nov 2007 06:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=6ELJRaDcwkK5IU9JnufBGvOaiJ2KcOmc/nMqAydhh5I=; b=exsgbF/+HC5URVmbI38chxJgw+jXbYkx8wI6o79LEOF5o2/kDCJGze+FHcvwM06N7yYBwzKl8zW8mWKXkRNoI5Vvq4LloMZW1W2fdpkTLNYzREclLAXlqg6xz79FBbPfJfhJTIK14EYATJ6e5PWe6iENn8SKCpaLqKN4oY/3Fl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=g9VwYZJxioAjUitlOF9hC6nOCvXT1NN+BROLuioCZACyyhe4pN7gFAPgHcZZ8Fpk8q972Wn51NoKLWF2x1vd+gcPbbpMemTz/i/rJKIg+oXa2tY7pRowOWfE84oHgY9QPSEY0OypQ0MJ2ZrK7Gp6Y0Ewj0tsC0DnCLIBztECziI= Received: by 10.86.50.8 with SMTP id x8mr2469876fgx.1194703502948; Sat, 10 Nov 2007 06:05:02 -0800 (PST) Received: by 10.86.90.4 with HTTP; Sat, 10 Nov 2007 06:05:02 -0800 (PST) Message-ID: <3bbf2fe10711100605h6b12238au7cc9d0fc6d1afde@mail.gmail.com> Date: Sat, 10 Nov 2007 15:05:02 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <63473.1194687277@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10711081135y3473817ejbc72574e3e8c763d@mail.gmail.com> <63473.1194687277@critter.freebsd.dk> X-Google-Sender-Auth: 08240306476b2cdb Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] callout overhaul: part I 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: Sat, 10 Nov 2007 14:05:16 -0000 2007/11/10, Poul-Henning Kamp : > 1. About the name > ------------------ > > In my proposal I used a generic XXX_ prefix, because nailing the > name was not the bikeshed I wanted to paint. > > You have chosen "callout" but I'm not sure I like that very much, > this is not really a callout facility, it is a timer facility. > > I don't like when core APIs have silly long names, that clutters > up source code needlessly, so my preference would probably be > to use a short prefix, something like "tmr", "when", "wake" or > similar. > > But let's take that offline and not start a bikeshed here. Well, I have no name preference really, so if you have something better in mind it is good. For the moment however, as I'm concentrating in adding "missing support" I want to remain more callout compliant. > 2. About XXX_instances > ----------------------- > > You propose a XXX_arm() and a XXX_arm_cpu(). That is a pointless > limitation. > > My API proposal said specifically: > > > The functions above will actually be wrappers for a more generic > > set of the same family, which also takes a pointer to a callout-group. > > And I guess the meaning of this was too subtle, so I will elaborate: > > The fundamental function will be called > > XXX_arm_cg(struct xxx_group *cg, ...) > > The xxx_group argument can be NULL, in which case a group is > chosen for you by unspecified means. Is this group, in your idea, sorta of a node of the heap you previously discussed in the thread? > 3. Two stage conversion > ----------------------- > > You propose a two-stage conversion. That is a bad idea when we > can do it as efficiently with a one-stage conversion. > > Having thought a bit more about the conversion, I think the right > way to do this is parallel implementations: Lets add the new > API and start converting critical code to use it. This is good. Speaking of which, perforce can really help in breaking commits in mealpieces. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein