On Thu, Mar 28, 2013 at 3:53 PM, Greg Kroah-Hartman
wrote:
> On Thu, Mar 28, 2013 at 01:13:23PM -0700, Luis R. Rodriguez wrote:
>
>
>
>> This has me thinking if it makes sense to have an external driver tree
>> for staging drivers but lead by engineers who already know the rules
>> of upstream,
On Thu, Mar 28, 2013 at 01:13:23PM -0700, Luis R. Rodriguez wrote:
> This has me thinking if it makes sense to have an external driver tree
> for staging drivers but lead by engineers who already know the rules
> of upstream, they just want to get things done faster.
That's called a "fork" or
Greg, folks,
So the staging area of the Linux kernel has proven quite successful
for a few drivers for 802.11 already. Otus [0] for example was
rewritten completely first as ar9170 [1] and then carl9170 [2] even
with open firmware, carl9170.fw [3] and then Otus got nuked. ath6kl
[4] is another
Greg, folks,
So the staging area of the Linux kernel has proven quite successful
for a few drivers for 802.11 already. Otus [0] for example was
rewritten completely first as ar9170 [1] and then carl9170 [2] even
with open firmware, carl9170.fw [3] and then Otus got nuked. ath6kl
[4] is another
On Thu, Mar 28, 2013 at 01:13:23PM -0700, Luis R. Rodriguez wrote:
huge snip
This has me thinking if it makes sense to have an external driver tree
for staging drivers but lead by engineers who already know the rules
of upstream, they just want to get things done faster.
That's called a fork
On Thu, Mar 28, 2013 at 3:53 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Thu, Mar 28, 2013 at 01:13:23PM -0700, Luis R. Rodriguez wrote:
huge snip
This has me thinking if it makes sense to have an external driver tree
for staging drivers but lead by engineers who already know
6 matches
Mail list logo
