[PVFS2-developers] Patch : Dynamic loading of BMI library
dbeilloi at mc.com
Wed Mar 23 07:41:30 EST 2005
> 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
> > 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
> 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.
More information about the PVFS2-developers