Wrappers to load bitmaps (Re: [PATCH] Improve ebitmap scanning)

[KaiGai Kohei]

Now I'm improving the performance to scan bitmap in SELinux,
with replacing its original bitmap implementation (ebitmap)
by common bitops like find_next_bit().

I posted a patch to replace them, however, it got a bit complex
bacause we had to translate u64 <--> unsigned long by myself
to adjust between the format of security policy and common bitops.
  http://marc.info/?l=selinux&m=118956715414494&w=2

I have an idea to provide several wrapper functions to copy u64/u32
to/from unsigned long for each architecture.
Maybe, it will be defined as follows:
  int arraycpy_u64_to_ulong(u64 *src, unsigned long *dest, size_t len);
  int arraycpy_ulong_to_u64(unsigned long *src, u64 *dest, size_t len);

I believe this feature will help getting code simpler and reducing bugs
for any other subsystem, not only SELinux, which loads bitmaps from/to
userspace and handle them using common bitops.

Any comment please.

Stephen Smalley wrote:
> On Thu, 2007-09-13 at 10:37 +0900, KaiGai Kohei wrote:
>> Paul Moore wrote:
>>> On Tuesday, September 11 2007 11:08:44 pm KaiGai Kohei wrote:
>>>> The attached patch applies the standard bitmap operations
>>>> for the iteration macro of ebitmap, and enables to improve
>>>> the performance in AVC-misses case.

  <...snip...>

>> BTW, is there any wrapper to copy an array of u64 to/from architecture specific
>> unsigned long? If so, it will help implement ebitmap_netlbl_{import|export}()
>> and ebitmap_read() more simply.
> 
> Might want to ask on linux-kernel.  More generally, it might be a good
> idea to cc linux-kernel on your next posting of the patch to get wider
> review of how you are using the native linux bitmap support.
> 
> The patch looks very promising, although a detailed review and testing
> might take a little bit.

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
-
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/