Messages in this thread Patch in this message | | | Date | Thu, 14 Feb 2008 13:16:39 -0800 (PST) | From | David Rientjes <> | Subject | Re: [RFC] bitmap relative operator for mempolicy extensions |
| |
On Thu, 14 Feb 2008, Ray Lee wrote:
> map_bitmap violates your naming convention, bitmap_map isn't all that > clear, bitmap_remap is taken, and while it is one-to-one and onto, I > think calling it bitmap_bijection would lose everyone except the > mathematicians. bitmap_onto? bitmap_map_onto? bitmap_map_bitmap_onto? >
Whatever this operation ends up being called should be mirrored in the name of the new mempolicy flag being introduced, so this will need to be finalized before MPOL_F_RELATIVE_NODES can be proposed.
> Minor suggestion: > + * and the n-th bit of @relmap is the m-th set bit of @relmap. > > Perhaps s/is the/is also the/, so that the reader doesn't try to > second guess if you accidentally wrote @relmap twice instead of one of > them being @orig. >
There's also an extra "is" in the description:
--- 2.6.24-mm1.orig/lib/bitmap.c 2008-02-04 10:41:35.656945848 -0800 +++ 2.6.24-mm1/lib/bitmap.c 2008-02-14 03:18:08.190311785 -0800 @@ -698,6 +698,69 @@ int bitmap_bitremap(int oldbit, const un } EXPORT_SYMBOL(bitmap_bitremap); +/** + * bitmap_relative - translate one bitmap relative to another + * @dst: resulting translated bitmap + * @orig: original untranslated bitmap + * @relmap: bitmap relative to which translated + * @bits: number of bits in each of these bitmaps + * + * Set the n-th bit of @dst iff there exists some m such that the + * n-th bit of @relmap is set, the m-th bit of @orig is is set,
on the last line of this snippet.
David
| |