[ofiwg] ofiwg item: supporting other OS's

[Jeff Hammond]

On Friday, January 8, 2016, Jason Gunthorpe <jgunthorpe at obsidianresearch.com>
wrote:

> On Fri, Jan 08, 2016 at 02:48:47PM -0800, Jeff Hammond wrote:
> >    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.
>
> ? gcc runs on almost everything, and generally isn't hard to
> install. Solaris, Windows, AIX, Mac OS, no problems. Most common cases
> have recent binary builds available.
>
>
According to knowledgable third parties, it is not available on the Fujitsu
K machine.

The version of GCC supported on Blue Gene/Q is 4.8.


> >    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.
>
> I wouldn't be that extreme.
>
> C11 support requires gcc 4.9 for full compiler features (yes, I know
> the library side is missing) and that is now nearly a two
> year old compiler.


Does GCC 4.9 support atomics? I don't have a binary handy...


>
> If it makes sense I wouldn't shy away from C11 features, many are very
> handy. And I wouldn't do a Windows port without a C11 compatible
> compiler.


I don't know that the group will go for anything past C99, but we should
try to enumerate the list of C11 features we would use if it were
permitted.

Of course, provider code can assume far more. The Cray provider uses C11
atomics...


>
> >    Let's make life miserable on everyone running Debian stable,
> >    CentOS 6.x, etc.
>
> CentOS 6 & 7 have RH supported packages for gcc 4.9 available via yum.
>
Debian stable already ships gcc 4.9
>
> A binary install is avaiable for Mac OS
>
> A binary is avaiable for Windows.
>
> Clang 3.7 equally supports C11, and provides binaries for windows and
> x86 linux.
>
> Don't overstate how hard the typical case is.
>
> Yes, the atypical case could be very hard, but
>
> >      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.
>
> That doesn't make any sense. A OS port is user a user visible top
> level feature. The toolchain is just a means to an end.
>
> I've got several software projects that are OS portable but not
> compiler portable (in the sense that they fully support many
> compilers, but often not the broken OS default one). I don't think
> that is inconsistent at all.
>
> Those projects require work to setup a build environment on certain
> OSs. That is less work than forever carrying patches for broken
> compiler support.
>
>
This all assumes that compilers aren't OS/HW dependent beyond the ISA. This
is not always true. Blue Gene/Q required a toolchain that aligned stacks to
32B instead of 16B, among other things. This is one reason why building GCC
from source is nontrivial.

Jeff


> It isn't for every project, but it is a very valid, and productive,
> way of approaching the problem.
>
> Especially now that the C standard bodies have worken up and are
> producing new standards more often. The C++ world feels this especially
> acutely.
>
> Jason
>


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