Re: [hwloc-devel] Priority of env vars vs. application options
On Oct 28, 2009, at 9:54 AM, Brice Goglin wrote: It's not (only) about buggy applications, the bug could in hwloc as well. You might want to check the hwloc behavior with this application if the topology if different. If it's just an hwloc developer thing, then perhaps it should only be enabled in debug builds...? And perhaps it can be a super-secret / not-public-interface / back-door environment variable that supersedes all others. -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] Priority of env vars vs. application options
Jeff Squyres wrote: > On Oct 28, 2009, at 9:29 AM, Samuel Thibault wrote: > >> > I would think that the API *only* looks at the names passed as >> > parameters -- command line, env variable, etc. are upper-layer >> > abstractions added by top-level tools like lstopo, etc. >> >> See Brice's case, where it's not the user that provides the xml file, >> but a deployment tool. >> > > > Ya, I saw that. For a small tool like the hwloc library, it doesn't > feel right to offer back-door hooks that can circumvent the > application. If an application is buggy, then the application should > be fixed -- it doesn't seem like the right thing to intentionally add > hooks just to accommodate buggy applications. Is that what you're > suggesting, or am I missing the point? > It's not (only) about buggy applications, the bug could in hwloc as well. You might want to check the hwloc behavior with this application if the topology if different. Brice
Re: [hwloc-devel] Priority of env vars vs. application options
On Oct 28, 2009, at 9:29 AM, Samuel Thibault wrote: > I would think that the API *only* looks at the names passed as > parameters -- command line, env variable, etc. are upper-layer > abstractions added by top-level tools like lstopo, etc. See Brice's case, where it's not the user that provides the xml file, but a deployment tool. Ya, I saw that. For a small tool like the hwloc library, it doesn't feel right to offer back-door hooks that can circumvent the application. If an application is buggy, then the application should be fixed -- it doesn't seem like the right thing to intentionally add hooks just to accommodate buggy applications. Is that what you're suggesting, or am I missing the point? -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] Priority of env vars vs. application options
Jeff Squyres, le Wed 28 Oct 2009 09:26:03 -0400, a écrit : > Can you pass XML filenames via the API? Yes, to cache the result for instance. > I would think that the API *only* looks at the names passed as > parameters -- command line, env variable, etc. are upper-layer > abstractions added by top-level tools like lstopo, etc. See Brice's case, where it's not the user that provides the xml file, but a deployment tool. Samuel
Re: [hwloc-devel] Priority of env vars vs. application options
On Oct 28, 2009, at 9:21 AM, Samuel Thibault wrote: > - command line > - env variable > - compiled-in defaults > > If you're in an environment where you can't pass command line options, > then use the environment (either explicitly set or unset it). But what about the situation that Brice suggested, i.e. the application itself using xml files internally? Where in the list should that be? Can you pass XML filenames via the API? I would think that the API *only* looks at the names passed as parameters -- command line, env variable, etc. are upper-layer abstractions added by top-level tools like lstopo, etc. -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] Priority of env vars vs. application options
Jeff Squyres, le Wed 28 Oct 2009 09:16:26 -0400, a écrit : > I would think that consistency across all tools is best: > > - command line > - env variable > - compiled-in defaults > > If you're in an environment where you can't pass command line options, > then use the environment (either explicitly set or unset it). But what about the situation that Brice suggested, i.e. the application itself using xml files internally? Where in the list should that be? Samuel
Re: [hwloc-devel] Priority of env vars vs. application options
That seems quite confusing. I would think that consistency across all tools is best: - command line - env variable - compiled-in defaults If you're in an environment where you can't pass command line options, then use the environment (either explicitly set or unset it). Just my $0.02... On Oct 27, 2009, at 7:38 PM, Samuel Thibault wrote: Brice Goglin, le Wed 28 Oct 2009 00:04:48 +0100, a écrit : > So I am not sure which order is the best. Maybe provide the two possibilities, i.e. two series of en vars, one that comes before the application configuration and the other that comes after? Samuel ___ hwloc-devel mailing list hwloc-de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] Priority of env vars vs. application options
Brice Goglin, le Wed 28 Oct 2009 00:04:48 +0100, a écrit : > So I am not sure which order is the best. Maybe provide the two possibilities, i.e. two series of en vars, one that comes before the application configuration and the other that comes after? Samuel
Re: [hwloc-devel] Priority of env vars vs. application options
Samuel Thibault wrote: > Hello, > > At the moment, the HWLOC_FSROOT and HWLOC_XMLFILE environment variables > override tool options and application configuration. Is it really the > behavior we should have? I'd tend to think that the priority order > should be: > > - application options/configuration > - environment variable > - default OS backend. > > i.e. basically move the HWLOC_FSROOT/HWLOC_XMLFILE interpretation to > hwloc_topology_init, before the application can override them through > configuration calls. Similarly, HWLOCK_THISSYSTEM would be overriden by > HWLOC_TOPOLOGY_FLAG_IS_THISSYSTEM. > For things like lstopo, we talked about it with Guillaume, and it seems clear that --xml should override HWLOC_XMLFILE. For other applications, I am not sure. I added HWLOC_XMLFILE to be able to dynamically switch to another topology for debugging purpose. If the application loads a XML file and the user finds that there is something wrong going on, being able to force-load another XML file might still be helpful. It's not clear that applications will let you change the XML file they load. For instance, it could be internal to the MPI process manager without ever exposing it to the user (process manager loads the topology once at startup, saves it as XML, and all MPI processes reload it from XML). In this case, being able to override with the env variable might be helpful. So I am not sure which order is the best. Brice
[hwloc-devel] Priority of env vars vs. application options
Hello, At the moment, the HWLOC_FSROOT and HWLOC_XMLFILE environment variables override tool options and application configuration. Is it really the behavior we should have? I'd tend to think that the priority order should be: - application options/configuration - environment variable - default OS backend. i.e. basically move the HWLOC_FSROOT/HWLOC_XMLFILE interpretation to hwloc_topology_init, before the application can override them through configuration calls. Similarly, HWLOCK_THISSYSTEM would be overriden by HWLOC_TOPOLOGY_FLAG_IS_THISSYSTEM. What do people think? (At least we should probably settle that clearly in the documentation) (and document these environment variables, I didn't know about HWLOC_XMLFILE). Samuel
