Jeff Squyres wrote:
Based on discussions at SC, I think it is time to have another IB/
OpenFabrics OMPI pow wow teleconference. It would be good to get
status updates on what everyone is doing in terms of OpenFabrics kinds
of things in OMPI so that we can coordinate the work properly. I'd
On Nov 19, 2007, at 6:56 AM, Pavel Shamis (Pasha) wrote:
- Cisco
- Voltaire
- LLNL
- OGC (Chelsio)
- ?ORNL?
- ?Sun?
Please add Mellanox to the list too ...
Oops! That was clearly a typo/oversight, sorry...
--
Jeff Squyres
Cisco Systems
I'm not sure it is really necessary - the problem is solely within
opal_cmd_line_parse and (if someone can parse that code ;-)) is truly simple
to fix. The overly long cmd line issue is due to a bug that Josh was going
to look at (may already have done so while I was out of touch).
Ralph
On 11/
Sorry -- I'm just joining this conversation late: what's the problem
with opal_cmd_line_parse?
It should obey all quoting from shells, etc. I.e., it shouldn't care
about tokens with special characters (to include spaces) because the
shell divides all of that stuff up -- it just gets a char
My, you are joining late! ;-)
The problem is with MCA params that take string arguments. If we pass the
following:
-mca foo "my beloved string"
on the command line of an orted, we get a value for foo that includes the
quote marks. I verified this rather painfully when attempting to pass a
comman
Yo Galen
I'm not aware of any continuing discussion to totally remove the process
name from ORTE - I believe we coalesced to redefining how the jobid was
established to a procedure that doesn't require a name server. This hasn't
come over to the trunk yet, but will in the next couple of months.
A
I guess I don't see why this is an opal_cmd_line_parse() problem.
If you invoke executables through system(), then a shell is used and
quoting is necessary to preserve the individual string tokens (i.e.,
"my beloved string" would be passed to the application as one argv
token, without the q
Unfortunately, it -is- a significant problem when passing the params on to
the orteds, as Tim has eloquently pointed out in his original posting. I
guess I don't see why it would be a significant problem to just have
opal_cmd_line_parse do the "right thing" - if a string param is quoted, then
just
Sun would like to be represented at this meeting. Mon 10AM might be a
problem for Sun, any of the other times are good.
-DON
Jeff Squyres wrote:
Based on discussions at SC, I think it is time to have another IB/
OpenFabrics OMPI pow wow teleconference. It would be good to get
status updat
On Nov 19, 2007, at 10:01 AM, Ralph H Castain wrote:
Unfortunately, it -is- a significant problem when passing the params
on to
the orteds, as Tim has eloquently pointed out in his original
posting. I
guess I don't see why it would be a significant problem to just have
opal_cmd_line_parse do
Hmmm...okay, I get the message: if it is going to be fixed, then I have to
fix it on my end. ;-) Which means it ain't happening anytime soon, so Tim P
is the one left in the lurch.
Sorry Tim! Perhaps you can come up with a compromise that re-enables what
you want to do.
Ralph
On 11/19/07 8:11
On Nov 19, 2007, at 10:15 AM, Ralph H Castain wrote:
Hmmm...okay, I get the message: if it is going to be fixed, then I
have to
fix it on my end. ;-) Which means it ain't happening anytime soon,
so Tim P
is the one left in the lurch.
Sorry Tim! Perhaps you can come up with a compromise that
On 11/19/07 8:19 AM, "Jeff Squyres" wrote:
> On Nov 19, 2007, at 10:15 AM, Ralph H Castain wrote:
>
>> Hmmm...okay, I get the message: if it is going to be fixed, then I
>> have to
>> fix it on my end. ;-) Which means it ain't happening anytime soon,
>> so Tim P
>> is the one left in the lurc
I am off all next week, but I will try to call in anyway..
- Galen
On 11/19/07 10:09 AM, "Don Kerr" wrote:
> Sun would like to be represented at this meeting. Mon 10AM might be a
> problem for Sun, any of the other times are good.
>
> -DON
>
> Jeff Squyres wrote:
>
>> Based on discussions
On Fri, Nov 16, 2007 at 11:36:39AM -0800, Jeff Squyres wrote:
> 1. Mon, 26 Nov, 10am US East, 7am US Pacific, 5pm Israel
> 2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel
> 3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel
> 4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel
>
Friday -- right, duh. My bad. So with everyone's replies so far, I
think we're down to:
2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel
3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel
4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel
If we get no more requirements, I
Jeff Squyres wrote:
Friday -- right, duh. My bad. So with everyone's replies so far, I
think we're down to:
2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel
3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel
4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel
3 or 4 will
Are there API functions or data structures that can be used to
determine if the 1-to-many model is supported on the system?
More specifically: can you have your configure.m4 script check to see
if the current system a) supports SCTP, and b) if yes, if it supports
1-to-many? This kind of ch
On Monday 19 November 2007 09:42:21 am Ralph H Castain wrote:
> An alternative solution might be to incorporate the modex in the new OMPI
> framework I was about to create anyway. This framework was intended to deal
> with publish/lookup of OMPI data to support a variety of methods.
> Originally,
This patch will fix the problem -- the OMPI_VAR_SCOPE stuff didn't
make it over to the v1.2 branch:
Index: config/ompi_config_asm.m4
===
--- config/ompi_config_asm.m4 (revision 16740)
+++ config/ompi_config_asm.m4 (working copy
On 11/19/07 6:20 PM, "Tim Prins" wrote:
> On Monday 19 November 2007 09:42:21 am Ralph H Castain wrote:
>
>> An alternative solution might be to incorporate the modex in the new OMPI
>> framework I was about to create anyway. This framework was intended to deal
>> with publish/lookup of OMPI
21 matches
Mail list logo
