[openib-general] [openfabrics-ewg] OFED 1.1-rc2 is ready

[Michael S. Tsirkin]

Quoting r. Doug Ledford <dledford at redhat.com>:
> Subject: Re: [openfabrics-ewg] OFED 1.1-rc2 is ready
> 
> On Sat, 2006-08-26 at 22:42 +0300, Michael S. Tsirkin wrote:
> > Quoting r. Doug Ledford <dledford at redhat.com>:
> > > IOW, make use of the infrastructure
> > > provided in U4 instead of working around it.
> > 
> > Sorry, I don't really understand what you suggest here.
> > Could you give us an example please?
> 
> Sure.

I get the idea now, but that's exactly what we tried to do.
I went over the patches, and here's what I found:

> The stock 2.6.9 kernel doesn't include kzalloc() or kstrdup().
> However, both of those exist in the Red Hat RHEL4 U3 and later kernels
> (yeah, I know, there isn't an easy way to know this, but unless you just
> *need* to support a U2 or earlier kernel, then you can just assume Red
> Hat has this).

I just checked and we don't override kzalloc except in the ipath
driver - see below about that. Are there other specific examples?

> Likewise, the U4 and later kernels have the proper class
> functions in the core kernel so you don't need small backports of stuff
> like class_create in the uverbs_main patch.

Again, U4 patch for uverbs main is smaller than for U3,
we removed all the class_device_create re-implementation.
Can it be made even smaller? How?

> Ditto for the get_sb_psuedo
> in the core patch.

Ditto, get_sb_pseudo is not re-implemented in our U4 patch.
So what's the issue?

> Ditto for a number of things in the ipath backports.

Please address this to ipath developers - they seem to prefer
keeping a single backport patch for multiple OS-es.

> Ditto for quite a few other things as well.

list?

> In general, there's less
> need to backport under RHEL4 U4 than previously, and where possible it
> would be best to make use of the core kernel's enhancements relative to
> a stock 2.6.9.

In general, ipath guys insist on keeping the same patch across distributions.
For other parts of the kernel that is exactly what we were trying to do.  Can
patches be made even smaller? Pls go ahead and suggest how.

-- 
MST