Date: Sat, 10 Nov 2007 15:05:02 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] callout overhaul: part I Message-ID: <3bbf2fe10711100605h6b12238au7cc9d0fc6d1afde@mail.gmail.com> In-Reply-To: <63473.1194687277@critter.freebsd.dk> References: <3bbf2fe10711081135y3473817ejbc72574e3e8c763d@mail.gmail.com> <63473.1194687277@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/11/10, Poul-Henning Kamp <phk@phk.freebsd.dk>: > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10711100605h6b12238au7cc9d0fc6d1afde>