[PVFS2-developers] Patch : Dynamic loading of BMI library

[Beilloin, David]

> De : Pete Wyckoff [mailto:pw at osc.edu] 
> dbeilloi at mc.com wrote on Fri, 18 Mar 2005 10:34 -0500:
> > In attachment is a new patch to support BMI dynamic shared library, 
> > Based on your previous input.
> > 
> > This options is off by default, and can be enabled at 
> configure time 
> > with --enable-dynamic-bmilib,
> > 
> > When enabled ALLOW_DYNAMIC_BMILLIB is defined in CFLAGS and 
> activate 
> > the Small part of code for this features, and binary are 
> link with -ldl.
> > 
> > When not no change are made compared to the current way it works.
> > 
> > Concerning scripts, pvfs2-genconfig is updated to check in the case 
> > where the choosen protocol is not tcp, gm or ib if a shared 
> library is 
> > available for the required protocol (base on its name 
> > libbmi_<protocol>) to do this pvfs2-genconfig call a simple program 
> > responsible for checking the existence Of such library and 
> its symbols.
> 
> Where is the rest of the patch that generates libbmi_tcp.so 
> et al., with their "method_interface" symbols too?  And 
> makefile/configure glop to generate and install them.
I didn't make such patch yet, I will do it soon.

> I don't understand the need to change pvfs2-genconfig.  Are 
> you imagining a situation where an out-of-tree BMI device 
> will be used with a stock pvfs2-genconfig? 
Yes, it was my goal (see below).

> Otherwise why not 
> just modify genconfig so it understands about your new BMI 
> device and ship your out-of-tree device with the patch?

My primary goal, is to package a standard pvfs2 rpm in a Linux
distribution and provide (only when specific hardware are ship) a 
package containing a dynamic lib for this hardware, and avoid
To ask the user to patch and/or recompile the stock pvfs2 source from
scratch to support a new dynamic bmi layer.

As this features is not link to my specific BMI but to the way layer are
configured (in pvfs2-genconfig) and load (bmi.c for dynamic lib), I was
thinking it could serve other bmi implementor and avoid each to patch
pvfs2 to allow a new support in particular when it's out of the cvs
tree.


> The dynamic loading part in bmi.c is sane.  I would prefer if 
> you would just rip out the code in BMI_addr_lookup below the 
> comment "if not found, try to bring it up now" and just 
> always call into activate_method().  That function can stay 
> like you have it:
>     1. check the active methods
>     2. check the known (static) but inactive methods
>     3. try the dynamic loader
> Can you clean up our old code like that?
Ok, I will do that soon too.

David.