Re: [Patch 5/23] mask v2 - Add new mask.h file

From: Paul Jackson
Date: Sat Apr 03 2004 - 00:16:13 EST


> I'm not a bit fan of the names of these macros ... MASK_ALL1 ...

Hmmm ... the way these names were, in this patch a couple of days
ago, they spanned files (defined in mask.h, used in cpumask.h).
So making the names a little "bigger" might make sense. I use "big"
names for stuff that is intended to be visible in larger namespaces.

However:

1) With yesterdays 24/23 patch, these names only span a few
lines in mask.h, so short cryptic names are perhaps more
appropriate.

2) The key issue here is whether the mask.h type is intended to
usable in its own right, only to generate various named
mask types.

We _could_ have three levels of coding multiword bit masks:

cpumask, nodemask, ...
mask
bitmap, bitops, plain old C

When I first started thinking about these a few months ago,
I intended to make both the mask and cpumask/nodemask level
widely usable. Now I don't think that's a good idea. Others
only need two levels:

cpumask, nodemask, ...
bitmap, bitops, plain old C

The 'mask.h' stuff now exists only to provide a common implementation
basis for the named mask types. Perhaps I should rename 'mask.h'
to something such as 'mask_innards.h' ... ;).

Notice the comment in mask.h, after the lengthy explanation of
bitmap, bitops, mask and cpumask/nodemask:

Summary:
Don't use mask.h directly - use cpumask.h and nodemask.h.

So, to make a long story short, the "unfriendly" names MASK_ALL1
fit their use. The solution to the problem of remembering what
they mean is ... don't use them ;).

What am I missing? What itch is not yet being scratched?

... hmmm ... "mask_innards.h" ... I rather like that.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@xxxxxxx> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/