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:
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@example.com/rhc/ompi-if
> devel mailing list
For corporate legal information go to: