tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: cpuset_t vs. cpu_set_t (again)

Anthony Mallet <> 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 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.


J.T. Conklin

Home | Main Index | Thread Index | Old Index