Message-ID: <46A6A76C.8010104@seclark.us>
Date: Tue, 24 Jul 2007 21:29:16 -0400
From: Stephen Clark <Stephen.Clark@seclark.us>
Reply-To: Stephen.Clark@seclark.us
MIME-Version: 1.0
To: Jeff Garzik <jeff@garzik.org>
CC: David Miller <davem@davemloft.net>, jketreno@linux.intel.com,
	axjslack@bluebottle.com, linux-wireless@vger.kernel.org,
	ipw3945-devel@lists.sourceforge.net
Subject: Re: [ipw3945-devel] Request for help...
References: <46A69998.7020108@seclark.us>	<20070724.173529.48529759.davem@davemloft.net>	<46A69CA1.5020706@seclark.us> <20070724.174641.105428420.davem@davemloft.net> <46A6A1F7.202@seclark.us> <46A6A619.300@garzik.org>
In-Reply-To: <46A6A619.300@garzik.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: linux-wireless-owner@vger.kernel.org

Jeff Garzik wrote:

>Stephen Clark wrote:
>  
>
>>I understand what you are saying on one hand, but you are also saying 
>>that Intel
>>is by themselves and no one in the community is going to help, if Intel 
>>can't figure
>>out how to do it the right way.
>>    
>>
>
>David referenced "the tireless attempts of Jeff and others to education 
>them on how to improve the situation"
>
>
>  
>
>>What I am saying why can't someone in the community be a liason
>>between what Intel is doing and wireless-dev? Why does it have to be 
>>someone from
>>Intel?
>>    
>>
>
>Ideally it is the hardware vendor that maintains their own Linux drivers 
>in the upstream kernel.  That is the ideal.  It scales best and focuses 
>knowledge and resources in everyone's best interests.
>
>To answer your question, it does not HAVE to be somebody at Intel.  On 
>occasion, when a hardware vendor was exceedingly difficult to work with, 
>someone in the community will step up and fill that gap.
>
>The problem with such a liaison is that they must maintain a fork of the 
>vendor driver themselves, which is time consuming and annoying, because 
>you wind up buffering the code and problem complaints from the community 
>as well as trying to reconcile that with new vendor driver engineering.
>
>That process, as we saw with skge and tg3 drivers, usually ends up with 
>the community maintaining a driver independent of the hardware vendor, 
>using the hardware vendor's driver purely as a reference manual, once 
>things are out-of-sync enough.  That's not generally a situation the 
>hardware vendor likes, since they lose a lot of control -- though in 
>tg3's case, the driver quality and upstream incentives were such that 
>the vendor switched from their own driver to tg3.  And now the tg3 
>vendor is back in control, actively submitting patches, and overall 
>being an excellent example of open source engineering done right.
>
>In general, most incentives rest on Intel to get stuff upstream.  That's 
>where the process is most efficient, and all involved (Linux users, 
>Kernel hackers, and Intel) benefit.
>
>Part of my tireless work is _not_ throwing my hands up in frustration 
>and doing it all myself :) but instead trying to counsel on where the 
>process is getting stuck.
>
>	Jeff
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>
Jeff,

Thanks for all you do and taking the time to explain what probably was 
apparent
already to a lot of people.

Steve

-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)