There was a prior discussion about utility providers reporting the underlying provider that they use. A proposal that introduced a 'comp_list' field into the fabric attributes was added to help with this. But, of course, this doesn't quite work...
The utility providers plug into the framework the same way core providers do. So they are subject to provider filtering (e.g. setting prov_name or FI_PROVIDER). Additionally, they use their own provider structure for log messages. Utility providers include an 'ofi-' prefix, so it's possible to special case. But we need to figure out how we want users to deal with their existence wrt filtering and logging. For discussion purposes, I've thought about adding an FI_UTILITY environment variable as a peer to FI_PROVIDER. But this is conceptually equivalent to creating FI_OTHER_PROVIDER. I also don't like the way comp_list behaves differently from other attributes, such as prov_name. E.g. can the app request specific utility components? How does that even work when they layer over each other? I've also thought about pushing the problem to the core providers. A core provider can use the generalized utilities to support the same features as the utility providers. This leaves us where we are today. I can see a benefit of users NOT needing to know about the utility components. But I also don't see an easy way to completely hide their existence. - Sean _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
