Closing the loop on this: I think I misunderstood George's comment. Looking thru the code, the MPI layer is indeed using the RTE names when defining things, so there is no inter-layer confusion. ORTE has no need to "own" the structure itself (except for non-MPI processes), so the existing code is fine.
On Jul 31, 2014, at 4:30 PM, Ralph Castain <r...@open-mpi.org> wrote: > > On Jul 31, 2014, at 3:41 PM, George Bosilca <bosi...@icl.utk.edu> wrote: > >> >> On Jul 31, 2014, at 18:26 , Jeff Squyres (jsquyres) <jsquy...@cisco.com> >> wrote: >> >>> George -- >>> >>> Got 2 questions for ya: >>> >>> 1. I see some orte_* specific symbols/functions in ompi_mpi_init.c. Was >>> that intentional? Shouldn’t that stuff be in the RTE framework, or some >>> such? >> >> Good catch. Fixed in r32384. >> >>> 2. In tracking down some stuff relating to process names, it looks like >>> names are now setting set by ompi/proc/proc.c (i.e., it makes a call to >>> opal_proc_local_set(...)). And this happens after the RTE is initialized. >>> Is that right? Seems a little weird to me — shouldn't the RTE be the one >>> that sets the process names? >> >> In my view the RTE should stay outside any local setting of the process. The >> RTE role is to move the info around, not to force it on everybody else. When >> multiple layers will use the BTL (and thus the OPAL level proc), we will >> have to figure out who will be responsible for setting the data into the >> OPAL level proc. Meanwhile, OMPI is the only one using this proc. > > > Uhhhh....not exactly. The dstore and pmi frameworks depend on it, and that > the name matches the one in the RTE. So ORTE is going to have to set that > proc object, and I imagine STCI will too. > > >> >> George. >> >>> >>> Thanks! >>> >>> -- >>> Jeff Squyres >>> jsquy...@cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> Link to this post: >>> http://www.open-mpi.org/community/lists/devel/2014/07/15407.php >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/07/15408.php
