Re: [ewg] [PATCH v4] IB Core: RAW ETH support

[Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

Jason Gunthorpe wrote:
> On Wed, Jun 16, 2010 at 12:12:06PM -0500, Steve Wise wrote:
>
>   
>>>> Granted our dev process may not be documented, but I always assumed 
>>>> the general idea was to get changes accepted upstream, then pull into 
>>>> ofed. OFED is just a mechanism to make top-of-tree linux work on 
>>>> distro kernels. There are some exceptions, but this stuff shouldn't 
>>>> be an exception.
>>>>         
>
>   
>>> That is what many people wish for, me included, but it is not at all
>>> what generally happens :(
>>>
>>> In my observation the typical flow is:
>>>  - A patch is written, it may or may not be sent to the list
>>>  - 'business drivers' get it slammed into OFED right away
>>>  - A patch is finally sent for proper review
>>>  - It is not merged, there are comments..
>>>  - Interest in doing anything is lost because it is already in
>>>    OFED and that is all that matters, right?
>>>  - People complain.
>>>
>>> For instance, the iWarp thingy we were just discussing fits this
>>> process rather well.
>>>       
>
>   
>> You're wrong.  I started that iWARP change in 2007 on LKLM.  I proposed  
>> a few ideas and show the pros/cons of each.  And it was NAKed 100% by  
>> mister miller.    It was then included in OFED as a last resort only  
>> because I couldn't get any help with trying to add this upstream in any  
>> form.  I even spent a few weeks developing a way to administor "iwarp  
>> only" ipaddresses, but Roland didn't like that scheme for various  
>> reasons.  So please don't mention that particular patch as a "bad  
>> process" unless you want to argue with me some more about it.
>>     
>
> Uhm, what you just described does fit my process outline:
>
>  #1 - Patch written, sent to LKML. Check.
>  #3 - Patch sent for proper review - in 2007. Check.
>  #4 - Not merged. NAK by DM. Check.
>  #2 - 'business drivers' force it into OFED - 'last resort' ie, iWarp
>       cards can't be used without some fix. Check.
>  #5 - Interest is lost. Yep, this was done in 2007, and it was idle
>       till now. Check.
>  #6 - People Complain. Hmm. Yep. Check.
>
>   

Note the ordering is different.  IE I tried very hard to get the "right" 
solution designed and agreed-upon upstream.  But failed.  That's my 
bad.    I did, however help with the iWARP core code including neighbour 
update net events which did go in upstream before ofed.

> Don't think I'm being critical toward only you, or singling out that
> little iWarp patch. But it really isn't special, or different, or an
> exception. Pick nearly any patch in OFED and someone will rush to its
> defense with a 'we tried to follow the process and it failed, so we
> did it anyway' argument.
>
> I also didn't say this is the only way that RDMA development goes,
> lots and lots of stuff goes into mainline first, from everyone.
>
> Jason
>   


OFED maintainers should be more rigid, perhaps, with requiring that 
changes be accepted upstream first.  One observation is that there is no 
"OFED RDMA maintainer", aka a Roland Dreier, for the OFED code.  So each 
driver maintainer pretty much has free reign to do the right thing or 
the wrong thing...


Steve.


--
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