Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] [PATCH] Open MPI on ARMv5
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2012-04-30 16:19:30

I'm good with it as long as you guys are.

Re the "...for now" comment; does this imply that you're going to do more later?

BTW, I assume this is for trunk and the v1.6 branch, right?

On Apr 30, 2012, at 9:47 AM, Leif Lindholm wrote:

> Thanks,
> I'm happy for this to go in - Jeff?
> /
> Leif
>> -----Original Message-----
>> From: nave.notnilc_at_[hidden] [mailto:nave.notnilc_at_[hidden]] On Behalf
>> Of Evan Clinton
>> Sent: 30 April 2012 05:12
>> To: Leif Lindholm
>> Cc: Open MPI Developers; Jeffrey Squyres
>> Subject: Re: [OMPI devel] [PATCH] Open MPI on ARMv5
>> Thanks again for the comments.
>>>> Quote the documentation, __kuser_cmpxchg "already includes memory
>>>> barriers as needed," so the code using it shouldn't need anything
>>>> extra.
>>> Fair enough - but could you put a comment to this effect into the
>> patch?
>> Comment added.
>>> But I'm still not too happy about even the very unlikely risk of
>>> something executing "random stuff" depending on kernel version.
>>> For now, could you update the comments to that effect that:
>>> "These kernel functions are available on kernel versions 2.6.15 and
>>> greater" + ", and running this software on earlier versions will
>> result
>>> in undefined behaviour."
>> Comment added.
>>> What I'm suggesting is not to parse information out of the build
>> host,
>>> but rather using the configured toolchain and options and try to
>>> assemble the 64-bit atomic instructions. This would make it easy to
>>> rebuild a generic ARMv6 package to support 64-bit atomics by just
>> adding
>>> -march=armv6zk to CFLAGS.
>> Ah, I get it. I may see if I can come up with a nice test in the near
>> future.
>> For now, revised patch attached.
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Jeff Squyres
For corporate legal information go to: