On May 18, 2010, at 8:31 AM, Terry Dontje wrote: > The above sounds like you are replacing the whole paffinity framework with > hwloc. Is that true? Or is the hwloc accessors you are talking about > non-paffinity related?
Good point; these have all gotten muddled in the email chain. Let me re-state everything in one place in an attempt to be clear: 1. Split paffinity into two frameworks (because some OS's support one and not the other): - binding: just for getting and setting processor affinity - hwmap: just for mapping (board, socket, core, hwthread) <--> OS processor ID --> Note that hwmap will be an expansion of the current paffinity capabilities 2. Add hwloc to opal - Commit the hwloc tree to opal/util/hwloc (or somesuch) - Have the ability to configure hwloc out (e.g., for embedded environments) - Add a dozen or two hwloc wrappers in opal/util/hwloc.c|h - The rest of the OPAL/ORTE/OMPI trees *only call these wrapper functions* -- they do not call hwloc directly - These wrappers will call the back-end hwloc functions or return OPAL_ERR_NOT_SUPPORTED (or somesuch) if hwloc is not available -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
