More specifically: if.h has not been changed (except for its finalize function).
So all this change does it un-spaghettify the if.c code. From an interface
perspective, the rest of the code base isn't even aware that this change
occurred.
Also, I think Ralph meant the following URL:
https://bitbucket.org/rhc/ompi-if
On Aug 24, 2010, at 5:11 PM, Ralph Castain wrote:
> Per the discussion on today's telecon, I've started working with Jeff on
> refactoring the opal/util/if.c code into something more understandable
> without changing the discovery logic. We are creating a framework that solely
> performs interface discovery, leaving all of the interface wrapper functions
> untouched. The various components are now configured in/out instead of being
> buried in multiple layers of #if.
>
> Jeff will be working on the configure logic in the near future. Meantime, the
> layout of the system is complete and everything builds as it should.
>
> Operation of the framework is straightforward. When framework open is called,
> it iterates through all available components and calls their open function.
> At that time, each component adds to the list of interfaces whatever it
> finds. The IPv4 interface discovery that was common across posix-based
> systems is located in a single component. The IPv6 discovery code, which
> tended to be highly system specific, is in separate components.
>
> As a result, there may be a change in the order in which interfaces are found
> on the list from where they appear today. However, this order was never
> guaranteed anyway, so any code that relied on it is incorrect and should be
> fixed.
>
> You are welcome to look at what is being done:
>
> hg clone https://[email protected]/rhc/ompi-if
>
> Ralph
>
> _______________________________________________
> devel mailing list
> [email protected]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
[email protected]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
