On Fri, Nov 20, 2015 at 3:06 AM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Nov 12, 2015 at 07:58:54AM +0200, Or Gerlitz wrote: >> On Sat, Oct 31, 2015 at 12:41 AM, <ira.weiny@xxxxxxxxx> wrote: >> So this is an wholy orthogonal mechanism for memory registrations or >> de-registrations vs what's supported by the upstream RDMA stack to which this driver >> attempts to be a HW provider, right? >> Ira, Mike - why do that? >> 2. Greg - I read an earlier comment you made that a driver in staging need to be 1st >> and most **fixed** with patches such that the TODO items to get it out >> of staging are addressed. I see here every day long train of features going into this >> driver, should the focus need to be elsewhere, according to the staging guidelines? > I've already complained about this, supposedly these are things that are > needed to get it out of staging... Greg, When the driver was picked by Doug to staging, the only major comment he has was the need to come up with shared code that implements IBTA transport in SW -- to avoid the code duplication between ipath, qib and hfi1 Indeed, work has been started to do that, but since hfi1 is in staging, none of the patches applied on it deal with that comment. I guess it should be OK that people sends cleanup once the driver is already there, buy should it be so heavily patched with new features? Mike? Doug? > And yes, you are correct. I know... _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
