[ofiwg] ofiwg item: supporting other OS's

Mccormick, Patrick M patrick.m.mccormick at intel.com
Fri Jan 8 11:25:21 PST 2016

I think mandating clang (or any compiler w/ >= c99 support) would be best too (and I thought we had it in our default cflags).

That will be the least of windows’ problems though—all that posix and linux specific code in core, plus the build system. Ming- or Cyg- win will be the easiest thing to port to.  Should probably open an issue to track all the requirements for the windows port.


From: ofiwg-bounces at lists.openfabrics.org [mailto:ofiwg-bounces at lists.openfabrics.org] On Behalf Of Jeff Hammond
Sent: Friday, January 8, 2016 11:13 AM
To: Jeff Squyres (jsquyres) <jsquyres at cisco.com>
Cc: OFIWG Mailing list <ofiwg at lists.openfabrics.org>
Subject: Re: [ofiwg] ofiwg item: supporting other OS's

Does libfabric assume C99?  MSVC is not a C99 compiler and never will be, according to every source I've ever seen (e.g. http://stackoverflow.com/questions/9610747/which-c99-features-are-available-in-the-ms-visual-studio-compiler, which links to MSFT docs that I cannot access).

Of course, Intel and others support a C99 compiler for Windows, but if Windows support implies supporting the platform's default compiler, then we need to worry about what MSVC supports.  Perhaps there is some automatic hook for Intel compilers in Visual Studio that mitigates the ISO shortcomings of MSVC.  Clang may also be an option (http://www.theregister.co.uk/2015/10/21/microsoft_promises_clang_for_windows_in_november_visual_c_update/).

Given the choice between limiting libfabric to a subset of C99 and not supporting Windows, I vote for C99 100 times out of 100.



On Fri, Jan 8, 2016 at 10:57 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com<mailto:jsquyres at cisco.com>> wrote:
On Jan 8, 2016, at 1:15 PM, Hefty, Sean <sean.hefty at intel.com<mailto:sean.hefty at intel.com>> wrote:
> As a discussion item for the next ofiwg, the topic has come up (again) about supporting other operating systems, specifically Windows and Solaris.

I would imagine that supporting Solaris with the configury/build/sockets providers wouldn't be too difficult...?

I don't know much about Windows to comment on it.

> At least two development teams have asked about support outside of Linux.  The desire is to code only to libfabric, with it dealing with differences in the underlying interfaces.  This is partially driven by the socket provider support inside libfabric, which allows for applications to remove their support for sockets.
> This in turn is driving the need for the sockets provider to focus on performance and scalability, rather than just functionality, which was the original goal.

Is it worth forking the sockets provider -- one for "simple" correctness (and not performance), and another optimized provider for sockets?

Jeff Squyres
jsquyres at cisco.com<mailto:jsquyres at cisco.com>
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

ofiwg mailing list
ofiwg at lists.openfabrics.org<mailto:ofiwg at lists.openfabrics.org>

Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20160108/75a75d51/attachment.html>

More information about the ofiwg mailing list