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

[Doug Ledford]

On Mon, 2007-03-19 at 00:34 +0200, Michael S. Tsirkin wrote:
> > Quoting Doug Ledford <dledford at redhat.com>:
> > Subject: Re: [ofa-general] OFED 1.2 Feb-26 meeting summary
> > 
> > On Mon, 2007-03-19 at 00:10 +0200, Michael S. Tsirkin wrote:
> > > > Quoting Jason Gunthorpe <jgunthorpe at obsidianresearch.com>:
> > > >
> > > > Basically, I wonder if the usefulness of a primarily source OFED
> > > > distribution is shrinking?
> > > 
> > > My laptop does not run either RHEL or SLES so I don't think so :).
> > > 
> > > > Maybe expanding the program to provide
> > > > RH/SuSE compatible source and binary upgrade RPMs is better?
> > > 
> > > Can't distributions do that? Why not?
> > 
> > Although not weekly or similarly frequent, RHEL4 and RHEL5 will both get
> > updates to the OFED sources at each scheduled update.  We won't be
> > freezing our OFED support with the initial supported release.
> 
> That's great.
> BTW, something that's I'd like to learn how to do, is a way to figure out what
> code is RHEL infiniband support based on.
> 
> For example, I gather RHEL5 basically has OFED 1.1, right?
> Does this include patches from the support page?

For RHEL4 and RHEL5, the base package is called openib.  The version,
aka openib-1.1, denotes the OFED distribution used to create the
package.  In fact, the name of the RPM and version are intended to
exactly match the name of the tarball I pulled out of the OFED
distribution.  As far as support patches go, I have included my own
patches to OFED to make it work reasonably given a /usr location, etc.
I have not downloaded any patches from the site that weren't part of the
OFED 1.1 tarball.  I did, however, apply all the fix patches that *were*
part of the OFED 1.1 tarball via the configure option to do so.

The kernel is handled separately.  For the kernel, I started with the
OFED 1.1 tarball, pulled the kernel sources, hand sorted through all the
fix patches that were labeled as appropriate for the given kernel, then
applied whatever fixups were needed to work with non-standard patches
that were in our kernel (like the inode-diet patch, which required
changes in the OFED kernel code, and Mike Christie, who handles our
iSCSI stack, took care of iSER specific fixups).  The kernel code will
always match the openib package.  When I update one, I update the other.
So, you always know the base by looking at the openib package version,
and then you can see any additional patches I've applied to user space
by looking at the openib.spec file, and you can see additional patches
to the kernel by looking for the main OFED patch (in RHEL4, it's patch
2700, in RHEL5 it's patch 2600), and immediately after or before the
main update patch will be the individual change patches that we've
applied.  However, keep in mind that in some cases, like in the RHEL5
case, the ofed-1_1 update patch is a pre-munged patch, meaning I applied
other patches to my working tree, then did a mondo diff between the
working tree and the source tree, so the individual patch information is
not complete there (fortunately, there wasn't much to patch at the time
since when we froze on 2.6.18, OFED 1.1 was running off that as a
starting base anyway).

For future releases, I want to start getting the libraries and such
separated out into different packages completely, including source.  So,
for RHEL6, I plan by then to be using totally separate packages each
pulled from a release version of that particular package, or if no such
tarball exists, from a release branch in the library's git repo.

-- 
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/20070319/6dffaf67/attachment.sig>