[ofiwg] ofiwg item: supporting other OS's

Jeff Hammond jeff.science at gmail.com
Fri Jan 8 14:48:47 PST 2016

On Fri, Jan 8, 2016 at 1:49 PM, Jason Gunthorpe <
jgunthorpe at obsidianresearch.com> wrote:

> On Fri, Jan 08, 2016 at 12:46:35PM -0800, Jeff Hammond wrote:
> >      Apparently soon you'll be able to use clang as the language
> >      front end on windows:
> http://www.theregister.co.uk/2015/10/21/microsoft_promises_clang_for_windows_in_november_visual_c_update/
> >
> >    I shared that link in my email.  I guess you stopped reading after the
> >    first paragraph :-)
> No, I just don't render HTML emails in my mailing list reader so I
> didn't see your link, I thought you were talking about the new native
> windows support within clang.

Use a good mailing list reader on all platforms ;-)

> >      Also, clang and gcc will both natively target windows now, and IIRC,
> >      there is even a way to just build windows DLLs straight from Linux
> >      with clang, so you can integrate with test infrastructure etc.
> >      Also, FWIW, RH supplies gcc 4.9 as an option on all their platforms
> >      now. Supporting a 'system' compiler is a really old fashioned
> >      idea. Use a good compiler on all platforms.
> >
> >    Sorry, I'm not trying to be rude here, but I cannot help myself to not
> >    use the following meme. I know Squyres will enjoy it :-)
> It has become an old fashioned idea because gcc and clang now nearly
> trivially cover a huge swath of cases people care about, and folks
> like RH have done the incredible, tedious, work to get new gcc's
> running on their old OSs, with the native system libraries.
> It's not a huge swath of cases.  It is a very large number of instances of
a very small number of cases.  I suspect that your huge swatch of cases
boils down to {Linux,BSD} x {x86(_64),ppc{32,64,64le},arm{32,64}}.  I guess
there might be a mips or a sparc in there, but what you are really saying
here is that you think two instantiations of POSIX represent the entirety
of computing.

> There will always be boutique places that have a hard time keeping
> current. But they are special, and it isn't fair to the developers to
> let them externalize their costs upwards into the ecosystems.

You're right.  libfabric should use as many features from C11 as possible
and expect everyone whose machine doesn't have GCC 5.3 and Clang 3.8 on it
to build their C compiler toolchain from source.  Let's make life miserable
on everyone running Debian stable, CentOS 6.x, etc.  Let's punish these
folks for having something better to do than upgrade their OS every Monday.

Additionally, all those supercomputer folks that were invited to contribute
to the design of OFI back in 2014 (or was it 2013?), let's make sure to
thank them for their time by waving an 18-inch foam middle finger in their
face because they might not have the ability to install an unsupported

Heck, why not insist that everyone who wants to run libfabric run Gentoo!
Only losers let someone else build their OS for them...

> The low-cost route for botique cases is pretty clear - get the
> toolchain patches upstream. Yes that is hard, I sympathize, but not
> enough to take patches supporting old systems on my projects :)

The GCC community refused to accept the Blue Gene/P patches upstream.  The
reason had nothing to do with the code, but some silliness related to a
publicly available processor manual.

> The old OFA effort to port the stack to Windows, IMHO, made a big
> mess. Ideologically requiring an old-at-the time MSVC compiler
> certainly contributed. Use a compiler that makes the port easy.

Why not just say "use an operating system that makes the port easy"?  It's
completely ridiculous to argue that OS portability matters but compiler
portability doesn't.  Be intellectually consistent and oppose the Windows
port or stop discussing this issue altogether.


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

More information about the ofiwg mailing list