On Mon, Sep 17, 2007 at 08:52:13PM -0400, David Holland wrote:

> On Sat, Sep 15, 2007 at 09:54:09PM +0300, Mindaugas R. wrote:
>  > > int pset_bind(psetid_t pset, idtype_t idtype, id_t id, psetid_t *opset);
>  > > int pset_create(psetid_t *newpset);
>  > > int pset_destroy(psetid_t pset);
>  > > int pset_assign(psetid_t pset, processorid_t cpu, psetid_t *opset);
>  > 
>  > The only thing I am not sure is a definition of psetid_t. After some
>  > thinking, perhaps such one would be OK for now:
>  > 
>  > typedef int32_t psetid_t;

What do you intend psetid_t to represent in the implementation? 32 bits is
not enough to represent a bitmask for CPUs.
 
>  > However, in future I would like to see the ability to control 64 and more
>  > processors in the set. The API allows dynamic allocation of the set, which
>  > would be fine for the userland, but perhaps not very conformable in the
>  > kernel. Any thoughts about these?
> 
> I think it would be best if it worked like sigset_t. But it looks like
> the API is already wrong for that...

For kernel-internal use how about a variation on /usr/include/bitstring.h?
That can be converted to use 32-bit types very easily, and the size can be
adjusted to match the machine. The one thing it would need is atomic
set/clear, though.

Thanks,
Andrew