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

[Paul Jackson <pj@sgi.com>]

> 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@sgi.com> 1.650.933.1373