On Sat, 2006-01-21 at 09:13 -0800, Sean Hefty wrote: > >> I don't see much urgency in merging it now. When svn diverges from > >> what's upstream in the kernel, it makes my life harder because I have > >> to figure out which patches belong upstream and sometimes merge things > >> by hand (when they hit the divergent regions). > > > >The easy solution here is not to diverge. Unless the iWARP support > >regresses IB functionality, it does no harm and creates a single > >software core for both iWARP and IB developers to bring new drivers to > >market. > > Until iWarp is integrated with the kernel,
It thought the approach was branch --> trunk --> kernel. What am I missing here? > the code will diverge however. And I > agree with Roland, merging diverged code upstream is a pain. No argument here. Merging code downstream is a pain too ;-) > I'm definitely > willing to re-organize the code to make it easier to maintain the code out of > the tree. Also, if we can isolate the IB/iWarp code into separate files, then > it's not a big issue pushing changes upstream. Making the code more modular is a good idea anyway. The provider and CM are already in separate files. At some point, though there is a single API and these files will have code for both transports (e.g. ib_verbs.h). One way to modularize the CMA is to have transport CM's register with the CMA and force all calls through function pointers ala verbs. > - Sean _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
