[ewg] Re: [ofa-general] OFED 1.2 Feb-26 meeting summary

[Doug Ledford]

On Wed, 2007-02-28 at 16:10 +0200, Tziporet Koren wrote:
>       * Improved RPM usage by the install will not be part of OFED
>         1.2 

Since I first brought this up, you have added new libraries, iWARP
support, etc.  These constitute new RPMs.  And, because you guys have
been doing things contrary to standards like the file hierarchy standard
in the original RPMs, it's been carried forward to these new RPMs.  This
is a snowball, and the longer you put off fixing it, the harder it gets
to change.  And not just in your RPMs either.  The longer you put off
coming up with a reasonable standard for MPI library and executable file
locations, the longer customers will hand roll their own site specific
setups, and the harder it will be to get them to switch over to the
standard once you *do* implement it.  You may end up dooming Jeff to
maintaining those custom file location hacks in the OpenMPI spec
forever.

Not to mention that interoperability is about more than one machine
talking to another machine.  It's also about a customer's application
building properly on different versions of the stack, without the
customer needing to change all the include file locations and link
parameters.  It's also about a customer being able to rest assured that
if they tried to install two conflicting copies of libibverbs, it would
in fact cause RPM to throw conflict errors (which it doesn't now because
your libibverbs is in /usr/local, where I'm not allowed to put ours, so
since the files are in different locations, rpm will happily let the
user install both your libibverbs and my libibverbs without a conflict,
and a customer could waste large amounts of time trying to track down a
bug in one library only to find out their application is linking against
the other).

>               * The RPM usage will be enhanced for the next (1.3)
>                 release and we will decide on the correct way in
>                 Sonoma.



There's not really much to decide.  Either the stack is Linux File
Hierarchy Standard compliant or it isn't.  The only leeway for decisions
allowed by the standard is on things like where in /etc to put the
config files (since you guys are striving to be a generic RDMA stack,
not just an IB stack, I would suggest that all RDMA related config files
go into /etc/rdma, and for those applications that can reasonably be run
absent RDMA technology, like OpenMPI, I would separate their config
files off into either /etc or /etc/openmpi, ditto for the include
directories, /usr/include/rdma for the generic non-IB specific stuff,
and possibly /usr/include/rdma/infiniband for IB specific stuff, or you
could put the IB stuff under /usr/include/infiniband, either way).

The biggest variation from the spec that needs to be dealt with is the
need for multiple MPI installations, which is problematic if you just
use generic locations as it stands today, but with a few modifications
to the MPI stack it could be worked around.


-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20070228/9e0910dd/attachment.sig>