[Drbd-dev] Re: drbd-user post from paul.clements@steeleye.com requires approval

[Philipp Reisner]

Am Dienstag, 3. Mai 2005 21:58 schrieben Sie:
> Hi again. I took your suggestion and copied the find_next_bit function
> from the kernel sources into the drbd header and used that. It worked. I
> guess the "generic" find_next_bit does not work correctly on ppc64.
>

Seems so. 

> So how should we patch this? I can add the ppc64 find_next_bit into the
> drbd headers, but because the kernel declares find_next_bit also, we
> have problems...how would you prefer we work around that? I have worked
> around it by renaming the drbd find_next_bit to generic_find_next_bit
> and changing the one call that drbd makes to that function...
>

Hi Paul,

Hmmm, slowly I understand the problem:
1) The kernel headers have a prototype "extern find_next_bit()"
2) On the other architectures it is an inlined function, therefore
   the drbd_comapt_types.h expects it to be inlined.

* What's about appending the ppc64 variant of find_next_bit() to 
  drbd_bitmap.c as global function, bracketed in #ifdef PPC64.
  And some tweaking to drbd_comapt_types.h so that it works ?

* I prefer this over renaming the find_next_bit() calls to 
  something else, because find_next_bit() is a part of 
  Linux-2.6's API.

-Philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :