[lkml]   [2004]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] mask ADT: bitmap and bitop tweaks [1/22]
    My thinking on when to worry about the unused bits, and when not to, is

    For the lib/bitmap.c code, it seems that the existing standard, followed
    by everything except bitmap_complement(), is to not set any unused bits
    (at least when called with correct arguments in range), but to always
    filter them out when testing for some Boolean condition or scalar result

    So I fixed bitmap_complement() to also not set them, and I put checks in
    my new Booleans bitmap_subset() and bitmap_intersects(), to filter them

    But I didn't worry about them in bitmap_xor() or bitmap_andnot(), just
    like the similar bitmap_or() and bitmap_and() don't worry about them
    (proper calls of or/and/xor/andnot will not set the unused bits anyway.)

    The standard I set for the include/linux/mask.h code is different than
    for lib/bitmap.c. In the mask.h code, I won't set them if all your
    calls are proper and in range (same as bitmap), but I also make no
    effort to filter them out on Boolean or scalar ops (though if some
    bitmap op I happen to call does filter such, I don't worry about it).

    So with the bitmap API, you can get unused bits set, and not notice it
    in most cases, due to the filtering. But with the mask API, you'd best
    not screw up and set them, or else you might get different Boolean and
    scalar results, depending on implementation details.

    My biggest defense against coding bugs in kernel code using these masks
    is to get the cpumask and nodemask API easier to understand and use.
    This should reduce bugs do to coder confusion. So long as they call
    this stuff with proper arguments, all is well.

    The bitmap stuff probably does more checking than I would like, but I
    felt it was more important to be consistent there, as bitmaps are an
    exposed API in their own right. Either add unused bit zeroing and
    filtering in the remaining places (complement and the new subset and
    intersects), or rip it all out.

    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <> 1.650.933.1373
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:02    [W:0.022 / U:30.672 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site