[openfabrics-ewg] Re: How to generate IBED releases using 1.0branch

[Tziporet Koren]

Hi,

 

This is the technical details you can use to send such a mail.

 

We are working on IBED release in collaboration of OpenFabrics release.

 

The motivation behind the release:

-          Backport IB support from 2.6.17 to older kernels and existing
distributions (Redhat, SuSE)

-          Making it easy for people to test and use components that are
not yet in mainline kernel

-          One package supported by all IB OEMs and vendors

-          Please add more ...

 

The components of the IBDE release are (in brackets is the source
location):

Kernel modules:

-          HCA drivers: mthca, ipath (git tree for 2.6.17)

-          core (all modules) (git tree for 2.6.17)

-          IPoIB (git tree for 2.6.17)

-          SRP (git tree for 2.6.17)

-          iSER (svn trunk)

-          SDP (svn trunk)

-          RDS: from SilverStorm contrib directory (till they move it to
the trunk)

User level modules:

-          All libraries and utilities from the 1.0 branch

-          Opensm from the 1.0 branch

 

MPI:

-          OSU MPI - tarball based on release 0.97 provided by Mellanox

-          Open MPI - tarball based on XXX (Jeff to fill) provided by
Cisco

 

In the way this release is done both IBED release and OpenFabrics share
the same user space code, and testing done on one of them contribute to
both.

Also working on kernel modules that are aimed for Linux kernel will
raise the quality level of Infiniband kernel code and will be aligned
with Linux releases.

 

More information that you may want to add is that we will use the same
bugzilla to report bugs

 

Tziporet

 

-----Original Message-----
From: Shawn Hansen (shahanse) [mailto:shahanse at cisco.com] 
Sent: Wednesday, March 29, 2006 8:33 PM
To: Sujal Das; bos at pathscale.com; Tziporet Koren
Cc: Michael S. Tsirkin; Openfabrics-ewg at openib.org
Subject: RE: [openfabrics-ewg] Re: How to generate IBED releases using
1.0branch

 

As far as communicating our plans to the openib-general: 

 

I'd like to request the development lead(s) to draft a technical summary
of a) what components are going to be included in IBED; b) how it
relates to the main OpenFabrics release; and c) any other information we
feel the community would like to see.

 

I'll then edit and craft a broader message based on this core material.

 

--Shawn

 

________________________________

From: openfabrics-ewg-bounces at openib.org
[mailto:openfabrics-ewg-bounces at openib.org] On Behalf Of Sujal Das
Sent: Wednesday, March 29, 2006 8:12 AM
To: 'bos at pathscale.com'; Tziporet Koren
Cc: Michael S. Tsirkin; 'Openfabrics-ewg at openib.org'
Subject: Re: [openfabrics-ewg] Re: How to generate IBED releases using
1.0branch

Communicating to open fabrics general - the proposal was for the
nominated chair, Shawn, to do so. 

-----Original Message----- 
From: Bryan O'Sullivan 
To: Tziporet Koren 
CC: Michael S. Tsirkin; Openfabrics-ewg at openib.org 
Sent: Wed Mar 29 08:00:45 2006 
Subject: [openfabrics-ewg] Re: How to generate IBED releases using 1.0
branch 

On Wed, 2006-03-29 at 16:54 +0200, Tziporet Koren wrote: 

>      1. Any module that is already in the kernel will be taken from 
>         the git tree that is targeted for 2.6.17 
>
(http://www.kernel.org/git/?p=linux/kernel/git/roland/infiniband.git;a=s
ummary) 
>         This include the following: mthca, ipath (if I understand it 
>         should be in soon), core (all modules), ipoib, srp 
>      2. Kernel modules that are not in Linux kernel will be taken from

>         these directories: 
>         iSER, SDP - from the trunk 
>         RDS: from SilverStorm contrib directory (till they move it to 
>         the trunk) 

Sounds good to me. 

>      1. All user space code will be taken from the 1.0 branch. I will 
>         send all user space patches that are important for this 
>         release. If it's OK I can also check them in, or ask the 
>         maintainers as agreed to do so. 

I think the best thing to do is send patches, then commit to svn after 
say a day's delay in case anyone objects. 

>      1. MPI: 
>         MVAPICH - tarball is provided by Mellanox 

Why would we not want to build MVAPICH from SVN? 

>         Open MPI - tarball is provided by Cisco 

I'm reluctant to just use a tarball without any visibility into what's 
happening in its development.  Can we at least have a pointer to where 
the Open MPI development tree is, be it SVN or CVS or whatever? 

> I think this module can help us to progress both OpenFabrics and IBED 
> releases very well and also contribute for the stability of code that 
> is going to Linux kernel. 

Yep. 

> BTW - when do we go public to OpenFabrics general list? 

This should really have happened by now.  I'd like someone to put 
together a draft announcement, circulate it here, and then send it to 
openib-general once it's been whipped into shape. 

        <b 

_______________________________________________ 
openfabrics-ewg mailing list 
openfabrics-ewg at openib.org 
http://openib.org/mailman/listinfo/openfabrics-ewg 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20060330/0390c149/attachment.html>