Re: cpuset_t vs. cpu_set_t (again)

[jtc%acorntoolworks.com@localhost (J.T. Conklin)]

Anthony Mallet <anthony.mallet%useless-ficus.net@localhost> writes:
> Two weeks ago, I raised the question of renaming cpuset_t to cpu_set_t,
> so that we can be source-compatible with the Linux definition (which has
> cpu_set_t afaik).
>
> rmind suggested that this could be possible but I would like to know what
> has finally been decided, if anything has been decided.
>
> Thanks for your answer!
>
> Note: my problem comes from a stupid configure script that checks for
> pthread_setaffinity_np() and if it finds it, then decides to call it with
> a cpu_set_t parameter. I would like to avoid maintaining a separate patch
> if NetBSD is going to change the type name...

I believe you mentioned this was in the ACE/TAO configure script. I do
much/most of the maintenence on it, so if NetBSD keeps using cpuset_t,
I'll probably end up improving the ACE feature test to handle it.
I'll just need to get a -current VM set up first (my NetBSD system on
the ACE scoreboard is still running 3.0 w/version of the ld.so ctor/
dtor order patch Andrew Doran integrated into -current).

FWIW, this may be a place where a typedef that maps cpuset_t to
cpu_set_t for "compatibility" is appropriate, like u_intXX/uintXX,
u_short/ushort, etc.

    --jtc

-- 
J.T. Conklin