From: Paul Jackson <pj@sgi.com>
To: colpatch@us.ibm.com
Cc: linux-kernel@vger.kernel.org, mbligh@aracnet.com, akpm@osdl.org,
wli@holomorphy.com, haveblue@us.ibm.com
Subject: Re: [PATCH] mask ADT: new mask.h file [2/22]
Date: Mon, 29 Mar 2004 16:27:40 -0800 [thread overview]
Message-ID: <20040329162740.0ca8f6d5.pj@sgi.com> (raw)
In-Reply-To: <1080606618.6742.89.camel@arrakis>
Matthew wrote (of my recommendation to not use the mask type directly):
> Is this necessary, or just convenient?
Technically as you suspect, just convenient, except in the case of the
mask_of_bit() macro, as you observe.
I was adhering to the K.I.S.S. school here - just tell the user one
recommended way of using things, suppressing my engineering urge to
explain alternatives that had no real advantages.
> This paragraph seems a bit unclear.
That's an understatment. I left out a 'not' and didn't
explain half the cases. See my updates, below.
> I think that it wouldn't be terribly ugly to split out the 1 unsigned
> long special cases (bitmap_and, bitmap_or, etc) with #ifdefs.
Do you have in mind an ifdef per function, or putting
several functions inside an ifdef? If you think it
looks better - show us the code ;).
> test_and_set_bit((bit), (mask)._m) ?
yup.
Here's my cumulative patch of changes that I have gained so far
from your excellent feedback, and a couple I've noticed:
diff -Nru a/include/linux/mask.h b/include/linux/mask.h
--- a/include/linux/mask.h Mon Mar 29 17:21:41 2004
+++ b/include/linux/mask.h Mon Mar 29 17:21:41 2004
@@ -62,7 +62,7 @@
* Don't use mask.h directly - use cpumask.h and nodemask.h.
*
* The available mask operations and their rough meaning in the
- * case that "nbits == 8 * sizeof(single unsigned long)" are:
+ * case that "nbits == BITS_PER_LONG" are:
*
* __mask(nbits) Use to define new *mask types
* mask_setbit(bit, mask) mask |= bit
@@ -70,7 +70,7 @@
* mask_setall(mask, nbits) mask = ~0UL
* mask_clearall(mask) mask = 0UL
* mask_isset(bit, mask) Is bit set in mask?
- * mask_test_and_set(bit, mask) mask | bit ? 0 : mask |= bit
+ * mask_test_and_set(bit, mask) mask & bit ? 1 : (mask |= bit, 0)
* mask_and(dst, src1, src2) dst = src1 & src2
* mask_or(dst, src1, src2) dst = src1 | src2
* mask_xor(dst, src1, src2) dst = src1 ^ src2
@@ -155,8 +155,10 @@
*
* The underlying bitmap.c operations such as bitmap_and() and
* bitmap_or() don't follow this model. They don't assume
- * the precondition that unused bits are zero, and they do
+ * the precondition that unused bits are zero, and they do not
* mask off any unused portion of input masks in most cases.
+ * The bitmap operations that produce Boolean or scalar results,
+ * such as for empty, full and weight, _do_ filter out unused bits.
* However the underlying bitop.h operations, such as set_bit()
* and clear_bit(), do no sanitizing of their inputs, depending
* heavily on preconditions.
@@ -234,7 +236,7 @@
test_bit((bit), (mask)._m)
#define mask_test_and_set(bit, mask) \
- test_and_set_bit(bit, (mask)._m)
+ test_and_set_bit((bit), (mask)._m)
#define mask_and(dst, src1, src2) \
do { \
diff -Nru a/lib/bitmap.c b/lib/bitmap.c
--- a/lib/bitmap.c Mon Mar 29 17:21:41 2004
+++ b/lib/bitmap.c Mon Mar 29 17:21:41 2004
@@ -47,7 +47,7 @@
int bitmap_equal(const unsigned long *bitmap1,
const unsigned long *bitmap2, int bits)
{
- int k, lim = bits/BITS_PER_LONG;;
+ int k, lim = bits/BITS_PER_LONG;
for (k = 0; k < lim; ++k)
if (bitmap1[k] != bitmap2[k])
return 0;
@@ -63,7 +63,7 @@
void bitmap_complement(unsigned long *dst, const unsigned long *src, int bits)
{
- int k, lim = bits/BITS_PER_LONG;;
+ int k, lim = bits/BITS_PER_LONG;
for (k = 0; k < lim; ++k)
dst[k] = ~src[k];
@@ -149,7 +149,7 @@
int bitmap_intersects(const unsigned long *bitmap1,
const unsigned long *bitmap2, int bits)
{
- int k, lim = bits/BITS_PER_LONG;;
+ int k, lim = bits/BITS_PER_LONG;
for (k = 0; k < lim; ++k)
if (bitmap1[k] & bitmap2[k])
return 1;
@@ -165,7 +165,7 @@
int bitmap_subset(const unsigned long *bitmap1,
const unsigned long *bitmap2, int bits)
{
- int k, lim = bits/BITS_PER_LONG;;
+ int k, lim = bits/BITS_PER_LONG;
for (k = 0; k < lim; ++k)
if (bitmap1[k] & ~bitmap2[k])
return 0;
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373
next prev parent reply other threads:[~2004-03-30 1:24 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-29 12:12 [PATCH] mask ADT: new mask.h file [2/22] Paul Jackson
2004-03-30 0:30 ` Matthew Dobson
2004-03-30 0:27 ` Paul Jackson [this message]
2004-03-30 1:56 ` Matthew Dobson
2004-03-30 0:47 ` Paul Jackson
2004-03-30 1:53 ` Matthew Dobson
2004-03-30 2:06 ` William Lee Irwin III
2004-03-30 1:31 ` Paul Jackson
2004-03-30 1:27 ` William Lee Irwin III
2004-03-30 1:27 ` Paul Jackson
2004-03-30 6:38 ` William Lee Irwin III
2004-03-30 8:45 ` Paul Jackson
2004-03-30 10:19 ` William Lee Irwin III
2004-03-31 0:16 ` Ray Bryant
2004-03-31 0:14 ` Jesse Barnes
2004-03-30 2:07 ` William Lee Irwin III
2004-04-01 0:38 ` Matthew Dobson
2004-04-01 0:58 ` Paul Jackson
2004-04-01 1:11 ` Matthew Dobson
2004-04-01 1:18 ` Paul Jackson
2004-04-01 1:27 ` Andrew Morton
2004-04-01 1:35 ` Paul Jackson
2004-04-05 1:26 ` Rusty Russell
2004-04-05 7:05 ` Paul Jackson
2004-04-05 7:42 ` Rusty Russell
2004-04-05 8:08 ` Paul Jackson
2004-04-06 4:59 ` Rusty Russell
2004-04-06 6:06 ` Paul Jackson
2004-04-06 6:23 ` Nick Piggin
2004-04-06 6:34 ` Paul Jackson
2004-04-06 6:49 ` Nick Piggin
2004-04-06 6:59 ` Paul Jackson
2004-04-06 7:08 ` Paul Jackson
2004-04-06 7:03 ` William Lee Irwin III
2004-04-06 7:33 ` Paul Jackson
2004-04-06 6:39 ` Rusty Russell
2004-04-06 6:45 ` Paul Jackson
2004-04-06 7:24 ` Rusty Russell
2004-04-06 7:34 ` Paul Jackson
2004-04-06 10:40 ` Paul Jackson
2004-04-07 0:02 ` Rusty Russell
2004-04-07 1:49 ` Paul Jackson
2004-04-07 3:55 ` Paul Jackson
2004-04-06 6:55 ` Nick Piggin
2004-04-06 7:34 ` Paul Jackson
2004-04-06 7:02 ` Paul Jackson
2004-04-05 7:46 ` Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040329162740.0ca8f6d5.pj@sgi.com \
--to=pj@sgi.com \
--cc=akpm@osdl.org \
--cc=colpatch@us.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).