On Thu, Jul 16, 2015 at 07:18:46PM +0000, Marciniszyn, Mike wrote: > Greg, > > We are in the process of submitting an RDMA driver for the Intel OPA > architecture.
I have no idea what "OPA" is, sorry. > The current massive patch set is submitted to add the driver to the > infiniband tree. > > I'm wondering if the staging area is a better spot to land the driver at > first? That way everyone can see it being reworked and participate in that > process. > > Some considerations: > - There are today significant comments > o Use of write instead of some other control. > (See qib commit 4961772560d2, > http://marc.info/?l=linux-rdma&m=143455871310614&w=2 ) > o Use of sysfs as qib does > o Duplication of code (ipath, qib, hfi1) (we are removing ipath to > eventually help in that respect) > - Driver is still being developed > o If we put the driver into staging there will be a lot of patches from the > above rework as well as internal development > > Given these points (existing flaws, development dynamics), is staging > suitable? It's up to the IB maintainer if they are willing to let it be in stable as-is. If so, sure, but it needs to be stand-alone and have a TODO file listing what needs to be done. If no forward progress happens on it, I will delete it from the tree, this isn't a place for dumping code. You also have to be able to handle other people modifying / cleaning up the code, so be careful with your "internal development" that you sync up very often. In the end, this is going to take more time and work than you doing all of what is needed in your own private tree, but it's up to you. > Is there a better way to get the initial driver into staging (vs. a > massive patch set)? What's wrong with a big patch set? > I'm also interested in any comments you might have on Al's commit > message and alternatives (write, ioctl, generic netlink). I have no idea what "Al", or commit, you are referring to, sorry. greg k-h _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel