Date: Sat, 10 Nov 2007 14:12:07 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Attilio Rao" <attilio@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] callout overhaul: part I Message-ID: <64645.1194703927@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 10 Nov 2007 15:05:02 %2B0100." <3bbf2fe10711100605h6b12238au7cc9d0fc6d1afde@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3bbf2fe10711100605h6b12238au7cc9d0fc6d1afde@mail.gmail.com>, "Attil io Rao" writes: >> 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? It is the handle for the handler you want to use, whatever that is and however it is implemented. The binary heap will be one member of that struct I pressume, if the implementation does use a binary heap in the first place. Our first implementation would likely use the existing callout mechanism, so that the API conversion can be decoupled from the implementation of the new and smarter techniques. -- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64645.1194703927>