[openfabrics-ewg] OFED 1.1-rc2 is ready

[Tziporet Koren]

Doug Ledford wrote:

> 
> Not supporting ppc is a problem to a certain extent.  I can't speak for
> SuSE, but at least for Red Hat, ppc is the default and over rides ppc64.
> The ppc64 arch is less efficient than the ppc arch on ppc64 processors
> except when large memory footprints are involved.  So, for things like
> opensm, ibv_*, etc. the ppc arch should actually be preferred, and the
> ppc64 arch libs should be present for those end user apps that need
> large memory access.  That fact that dapl doesn't compile on ppc at all
> is problematic as well.  In addition, what are you guys doing about the
> lack of asm/atomic.h (breaking udapl compiles on ppc64 and ia64) going
> forward?  I'd look in the packages and see for myself but the svn update
> is taking forever due to those binary rpms packed into svn...ahh, it's
> finally done....ok, still broken.
> 

We don't have here any PPC machine for event for compilation checks :-(

> Without getting into an argument over the usage of that include, suffice
> it to say that the include file is gone and builds fails on
> fc6/rhel5beta.  Since the code really only uses low level intrinsics as
> opposed to high level atomic ops, I made a ppc and ia64 intrinsics
> header for linux and added it to the dapl package itself to work around
> the issue.
> 

Please work with James and Arlin to drive these changes to uDAPL.

> 
> Ugh.  Each library does not need it's own package.  Imagine what X would
> do to your RPM count otherwise.  For grouped libraries like this, it is
> perfectly acceptable to do opensm, opensm-libs, opensm-devel (and that's
> in fact what I did for RHEL4 U4).  Regardless though, make a decision
> and stick to it.  Changing package names with each release == not good.
> 

I agree - but we had to change since there was requirement from Cisco to 
include diagnostic tools and not opensm. It might be that we did it not 
in the best way and Vlad will check if he can improve it according to 
your directives.


>> 5. RHEL4 up4 is not supported due to problems in the backport patches.
> 
> You should be able to start by pulling the patches that are already
> applied out of the RHEL4 U4 kernel rpm, looking at which ones fix up the
> core kernel to provide what's needed instead of doing a thousand little
> backports all over the kernel tree, and axing any backport patches you
> had planned that would undo that.  IOW, make use of the infrastructure
> provided in U4 instead of working around it.
> 

We already fixed this and RHEL4 will be part of rc3.
We will also look at the way you did in RHEL4 up4 later and learn for 
future releases.

Tziporet