Re: shrink struct ib_send_wr V4

[Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>]

On Tue, Nov 03, 2015 at 11:59:02AM -0500, Chuck Lever wrote:
> 
> > On Nov 2, 2015, at 6:37 PM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > 
> > On Mon, Nov 02, 2015 at 06:20:40PM -0500, Doug Ledford wrote:
> >> 1) Aging, but working, drivers that will be removed in the future.
> >> Since we no longer have a deprecation mechanism, I was informed that the
> >> normal procedure now is to move the driver to staging for a while and
> >> then remove it permanently on a future schedule.  This provides an
> >> orderly removal process.  But, if you make it so that random people can
> >> break the driver with no responsibility for fixing up their breakage, in
> >> contrast to the entire rest of the kernel, then you eliminate that
> >> orderly removal process and turn it into a completely non-deterministic
> >> and chaotic removal process.  So, no, if that's how it will be handled,
> >> I will move the deprecated drivers back to the main rdma tree and time
> >> them out and perform the orderly removal myself.
> > 
> > So you have what, one more kernel release before these are deleted?
> > Odds are, nothing is going to be broken so badly that a simple patch
> > will not fix up before they are removed.  So don't worry about this.
> > 
> > And why would you want a developer wasting time on fixing up these
> > drivers if they are about to be deleted anyway?  Obviously no one even
> > uses them, otherwise they wouldn't be about to be removed.
> 
> I understand the stated policy, but I was recently
> bitten by it. I got dinged by the kbuild robot when I
> made a change that broke something in staging. I was
> caught between the staging policy and the guidelines
> about fixing kbuild nits before a merge window.
> 
> My change was in the IB core, but the breakage was in
> Lustre. Their fix (which was quick because I had warned
> them in advance) was substantial, and not something I
> could have provided myself.
> 
> If the bits in staging are truly to be ignored, then
> the kbuild robot shouldn’t warn about new staging
> breakage. Or the warning messages should state that
> fixing said breakage is optional.

You are always free to ignore the results of the 0-day bot for stuff
like this if you want to, that's your choice, it's just informing you of
the results of the build.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html