Re: shrink struct ib_send_wr V4

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

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.

> 2) New drivers (one currently, one other one submitted but not yet
> pulled in) under active development but which need specific things fixed
> up.  These have people already working on them full time.  They were
> submitted to the staging tree with a specific TODO in order to get out.
>  If you then break that driver and force the driver author to fix it,
> you have in essence changed the TODO list.  That means you now have a
> moving goal post scenario.

Again, this shouldn't be taking you all that long to get out of staging,
right?  And again, the number of api changes that cause breakage are
usually very minor, if they happen at all (remember, this is a
theoretical, not what usually happens.)  And a driver in this state
doesn't deserve to be in the "real" portion of the kernel, so you can't
merge it anywhere else, so overall it still benifits being in the
staging tree, so a few minor breakages every once in a while should be
easy for you to fix up, _if_ they happen.

Again, I don't know of any recent api change that has caused any
problems in a long time, but the VFS developers really hate having to
touch lustre code, and I don't blame them, so sometimes that codebase
breaks.  That will not affect your drivers at all, so I wouldn't worry
about this.

So relax, this isn't going to be an issue, or if it is, you can easily
handle it, it is no different from any other tree-wide api change that
happens.

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