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

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

[Philipp Reisner]

----------  Weitergeleitete Nachricht  ----------

Subject: Re: drbd-user post from paul.clements@steeleye.com requires approval
Date: Dienstag, 3. Mai 2005 17:57
From: Philipp Reisner <philipp.reisner@linbit.com>
To: Paul Clements <paul.clements@steeleye.com>

Am Montag, 2. Mai 2005 20:18 schrieben Sie:
> We've recently been trying to certify DRBD (we've tried both 0.7.5 and
> 0.7.10 with the same results) on ppc64 with RHEL3.
>
> Unfortunately, we have run into two fairly serious issues:
>
> 1) we had to hack up the source just to get it to build:
>
> The basic problem is that the adjust_drbd_config_h.sh script is not
> doing the right thing for RHEL3 on ppc64. RHEL3 has a find_next_bit()
> function, and on most architectures it's an inline function. However, on
> ppc64 it's not inline and it's not exported, which means drbd (being a
> module) can't use it. So we have to actually disable the
> HAVE_FIND_NEXT_BIT setting in drbd_config.h. Also, there is no
> arch-specific find_next_bit function for ppc64 in drbd_compat_types.h,
> so we have to use the generic find_next_bit function that's in that file
> (by defining USE_GENERIC_FIND_NEXT_BIT in drbd_config.h). Of course,
> when this function is defined, it conflicts with the previous
> find_next_bit function declaration from the kernel headers
> (asm-ppc64/bitops.h). So, we had to rename the generic function to
> generic_find_next_bit and change all calls in the drbd source (just one
> in drbd_bitmap.c) to use generic_find_next_bit instead of find_next_bit.
>
>
> 2) additionally, the driver appears to start up fine on both machines,
> but when the resync begins, it quickly stalls and never makes any progress

Hi Paul,

DRBD-0.7.10 works on Linux-2.6.x based distributions on ppc64.
I guess the way to go to get it to work on 2.4 is make it to use the
ppc64 specific find_next_bit() function.

I am ready to accept a patch, and to include this into 0.7.11, but
I do not have a ppc64 machine here to do it myself.

PS: The mailing lists only allows posts from subscribed addresses.

-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 :

-------------------------------------------------------

-- 
: 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 :

[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 :