[EMAIL PROTECTED] wrote on Thu, 21 Sep 2006 10:19 -0400:
> If I use a URI of mx://hostname:board:endpoint for each peer, I am
> wondering how the local bmi_mx gets its own name (in order to know
> which NIC to use and which MX endpoint).
>
> Looking through bmi.c, activate_method() calls
> BMI_meth_method_addr_lookup(listen_addr) before calling
> BMI_meth_initialize(). The function activate_method() is called from
> BMI_initialize() which indicates that listen_addr is "a comma
> separated list of addresses to listen on for each method." Should I
> assume that the following will happen to startup bmi_mx:
>
> new_addr = BMI_meth_method_addr_lookup("mx://
> myhostname:myboard:myport");
> ...
> BMI_meth_initialize(new_addr, ...)
>
> Is this a correct assumption for the method_addr_lookup() and order
> of operations?
Yes on the assumption, thus BMI_mx_method_addr_lookup() should not
look at any state that needs to be initialized in
BMI_meth_initialize. It just munges strings. The IB implementation
relies on a static variable to check if it has been initialized or
not.
I'm not thoroughly happy with this situation. If it is a major
problem for MX, speak up. We can fix the API.
> If so, then my method_addr_lookup() function has to check if bmi_mx
> has been initialized before using any lists, locks, etc., no?
In BMI_mx_initialize, do whatever basic NIC-independent setup you
need to do. If called with a non-NULL listen_addr, act as a server
and listen on the device passed in. To do that you'll have to
open the particular board in the address. Ideally you'd have a way
of listening on all boards since you don't know from where your
clients will come yet.
On a client, you don't know at initialize time to what server(s)
you'll need to connect. Somehow you'll have to prepare the device
as needed in the first sendunexpected call.
Does this work?
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
