Messages in this thread | | | Date | Tue, 6 Apr 2004 00:33:18 -0700 | From | Paul Jackson <> | Subject | Re: [PATCH] mask ADT: new mask.h file [2/22] |
| |
Don't worry, Bill. It doesn't look like anyone wants to change cpumask_t to struct cpumask. I just wasn't objecting to it - shouldn't even have mentioned it.
> so please run things by arch maintainers
I'll be doing that. And I'm sure Andrew wouldn't consider it otherwise.
> for the love of $DEITY, **NOT** "struct cpumask_struct".
I think we can all heartily agree to that advice.
> You should also bear in mind that the current implementations of these > operations use a macro calling convention, thereby altering their output > operands as a side-effect without call-by-reference.
Ah - I think you just explained to me Rusty's 'That'd be a noop', to which I had responded 'Huh?'. Thanks.
And the added ampersands that Rusty added a couple of messages before that.
Duh ... smacking forehead.
Output operands need to be passed by pointer (which fact may or may not be hidden in a macro ...).
At the risk of embarrassing myself again in public, how about this:
typedef struct { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
#define cpus_or(d,s1,s2) _cpus_or(&d, &s1, &s2)
static inline void _cpus_or(cpumask_t *d, const cpumask_t *s1, const cpumask_t *s2) { bitmap_or(d->bits, s1->bits, s2->bits, NR_CPUS); }
It would be used exactly as it is today:
cpumask_t x, y, z; cpus_or(x, y, z);
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.650.933.1373 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |