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

[Doug Ledford]

On 06/16/2010 02:35 PM, Steve Wise wrote:
> 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...

Yep, no doubt that has an impact on things.  It's for this very reason
that our next operating system is not following OFED but instead is
using upstream as its basis.  That will be true from now on with our
products.


-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20100617/5388d541/attachment.sig>