On 07/17/2015 02:14 AM, Greg Kroah-Hartman (gregkh@xxxxxxxxxxxxxxxxxxx) wrote: > 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. Omni-Path Architecture. It's Intel's answer to InfiniBand. >> 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. I wouldn't call it stable as-is. However, that doesn't mean I think it *must* go to staging. It's a first cut at a totally new driver. It's got issues, but they aren't horrible by my estimate. I don't consider staging a necessary step, although I wouldn't preclude it either. > 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. No, it's 50,000+ LOC already. I don't see "no forward progress" as likely. > 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? He's not talking about patch sets so much as file drops. The lists dropped several of his submissions for being too large the first time. If they were all small change patches, it wouldn't have been an issue. >> 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. Al...as in Al Viro, the most vitriolic person ever hired by Red Hat ;-) He really has a special place in our halls.... And I wouldn't expect you to get this reference. There was a recent commit by Al to one of Intel's other drivers that basically said "Drivers should *never* do this...", but it's been working fine for them, so they are looking for alternatives that don't cause Al to want to hunt them down as insult fodder, so they are gathering other opinions. The problem here is that the device file /dev/ipath has a special use separate from any other device file in the system and unique needs. Al applied general preferences to it. It's something we need to sort out, but wasn't probably an appropriate question for you, as evidenced by your lack of knowledge of the issue ;-) -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
