[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <005801d07870$3b2dc530$b1894f90$@opengridcomputing.com>
Date: Thu, 16 Apr 2015 13:07:41 -0500
From: "Steve Wise" <swise@...ngridcomputing.com>
To: "'Jason Gunthorpe'" <jgunthorpe@...idianresearch.com>,
"'Michael Wang'" <yun.wang@...fitbricks.com>
Cc: "'Roland Dreier'" <roland@...nel.org>,
"'Sean Hefty'" <sean.hefty@...el.com>,
"'Hal Rosenstock'" <hal.rosenstock@...il.com>,
<linux-rdma@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
"'Tom Tucker'" <tom@...ngridcomputing.com>,
"'Hoang-Nam Nguyen'" <hnguyen@...ibm.com>,
"'Christoph Raisch'" <raisch@...ibm.com>,
"'Mike Marciniszyn'" <infinipath@...el.com>,
"'Eli Cohen'" <eli@...lanox.com>,
"'Faisal Latif'" <faisal.latif@...el.com>,
"'Jack Morgenstein'" <jackm@....mellanox.co.il>,
"'Or Gerlitz'" <ogerlitz@...lanox.com>,
"'Haggai Eran'" <haggaie@...lanox.com>,
"'Ira Weiny'" <ira.weiny@...el.com>,
"'Tom Talpey'" <tom@...pey.com>,
"'Doug Ledford'" <dledford@...hat.com>
Subject: RE: [PATCH v3 27/28] IB/Verbs: Clean up rdma_ib_or_iboe()
> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgunthorpe@...idianresearch.com]
> Sent: Thursday, April 16, 2015 11:43 AM
> To: Michael Wang
> Cc: Roland Dreier; Sean Hefty; Hal Rosenstock; linux-rdma@...r.kernel.org; linux-kernel@...r.kernel.org; Tom Tucker; Steve Wise;
> Hoang-Nam Nguyen; Christoph Raisch; Mike Marciniszyn; Eli Cohen; Faisal Latif; Jack Morgenstein; Or Gerlitz; Haggai Eran; Ira
Weiny;
> Tom Talpey; Doug Ledford
> Subject: Re: [PATCH v3 27/28] IB/Verbs: Clean up rdma_ib_or_iboe()
>
> On Tue, Apr 14, 2015 at 11:13:03AM +0200, Michael Wang wrote:
>
> > > I would be very happy to see a patch that adds cap_ib_smi to the
> > > current tree and states 'This patch is tested to have no change on the
> > > binary compilation results'
> >
> > There are too much reform there (per-dev to per-port), I guess the binary
> > will changed more or less anyway...
>
> I think this patch series is huge, and everytime someone new looks at
> it small functional errors seem to pop up..
>
> Doing something to reduce the review surface would be really helpful
> here. Not changing the same line twice, using tools too perform these
> transforms and then assert the patch is a NOP because .. tools. Some
> other idea?
>
Don't try and change everything in one giant series. Just do some changes this cycle (keep it at < 8 or 10 patches), and do more
later...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists