lkml.org 
[lkml]   [2004]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.123 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site