Re: pthread_setaffinity_np(), cpuset_t, etc.

In article <87od8yziuh.fsforac.acorntoolworks.com>,
J.T. Conklin <jtcacorntoolworks.com> wrote:
>Hi folks,
>
>Back in February/March there was discussion about
cpuset_t as used by
>NetBSD and cpu_set_t as used by Linux. This was in the
context of the
>ACE/TAO configure script failing as it assumed
pthread_setaffinity_np
>and pthread_getaffinity_np uses cpu_set_t. I mentioned
that I was one
>of the ACE/TAO maintainers and that I'd do what's
necessary to get it
>to work whether NetBSD changed the name of to be more
compatible or 
>not.
>
>I'm still running a mix of NetBSD 3 and NetBSD 4, but I
created a
>-current VM to test this because there's a upcoming
ACE/TAO release.
>If at all possible, I'd like to do what is necessary to
add -current
>support.
>
>For the time being, I've added support to typedef
cpu_set_t in terms
>of cpuset_t.  But I wonder if this could cause problems
if various
>third party packages/libraries start doing the same. It
seems much
>better if NetBSD itself would provide this compatibility
typedef,
>similar to how it provides both uintXX_t and u_intXX_t,
u_short and
>ushort, etc.  I can send a PR with a patch if this seems
desirable.
>
>The second problem I ran into was that
pthread_setaffinity_np() takes
>a cpuset_t* argument, where ACE's wrapper facade assumes
it would be a
>const cpuset_t*.  Is there any reason why this is not? 
It appears
>that kernel treats the argument as const in the
underlying
>__sched_setaffinity system call as if it was a const
ptr.  I can send
>a PR with a patch if this seems desirable too.

Send-pr please

christos