On Fri, Mar 22, 2013 at 06:08:40PM -0400, Theodore Ts'o wrote:
[Insisting on upstream drivers]
> I've been waiting for this to start happening in the consumer
> electronics/embedded world, but it's been slow coming,
> unfortunately
For CE at least it's not really relevant as nobody's got much
On Sat, Mar 23, 2013 at 12:02:21PM -0700, Guenter Roeck wrote:
> On Fri, Mar 22, 2013 at 10:43:44AM -0400, Ben Collins wrote:
> > On Mar 22, 2013, at 10:33 AM, David Miller wrote:
> >
> > > From: Fleming Andy-AFLEMING
> > > Date: Fri, 22 Mar 2013 14:31:50 +
> > >
> > >> It would appear one
On Fri, Mar 22, 2013 at 06:08:40PM -0400, Theodore Ts'o wrote:
> On Fri, Mar 22, 2013 at 11:39:20AM -0400, Ben Collins wrote:
> >
> > If your company had hardware going to production, you'd want it supported
> > in mainline too, I suspect.
>
> And if companies told their hardware partners that t
On Fri, Mar 22, 2013 at 10:43:44AM -0400, Ben Collins wrote:
> On Mar 22, 2013, at 10:33 AM, David Miller wrote:
>
> > From: Fleming Andy-AFLEMING
> > Date: Fri, 22 Mar 2013 14:31:50 +
> >
> >> It would appear one of our customers is attempting to upstream our
> >> code for us. We are aware
On Fri, Mar 22, 2013 at 11:39:20AM -0400, Ben Collins wrote:
>
> If your company had hardware going to production, you'd want it supported in
> mainline too, I suspect.
And if companies told their hardware partners that they will drop use
of their hardware in future products unless they get thei
On Mar 22, 2013, at 12:16 PM, David Miller wrote:
> From: Ben Collins
> Date: Fri, 22 Mar 2013 12:14:44 -0400
>
>> I'm sorry, I thought we were working on open source projects
>> here. If the code isn't encumbered by patents, legal issues or
>> technical problems, and is licensed compatible wit
On Mar 22, 2013, at 11:59 AM, David Miller wrote:
> From: Ben Collins
> Date: Fri, 22 Mar 2013 11:53:54 -0400
>
>> Also, if there's a patch that makes my hardware work, but I can't
>> use it because (even though it's open source licensed) the author
>> doesn't want it in mainline, then that is
From: Ben Collins
Date: Fri, 22 Mar 2013 12:14:44 -0400
> I'm sorry, I thought we were working on open source projects
> here. If the code isn't encumbered by patents, legal issues or
> technical problems, and is licensed compatible with the kernel, I
> just thought it was fair game.
This is abo
From: Ben Collins
Date: Fri, 22 Mar 2013 11:53:54 -0400
> Also, if there's a patch that makes my hardware work, but I can't
> use it because (even though it's open source licensed) the author
> doesn't want it in mainline, then that is effectively squatting.
This is called respecting the wishes
On Mar 22, 2013, at 11:41 AM, David Miller wrote:
> From: Ben Collins
> Date: Fri, 22 Mar 2013 11:39:20 -0400
>
>> If your company had hardware going to production, you'd want it
>> supported in mainline too, I suspect.
>
> But never against the wishes of the author of the code.
>
> This has
From: Ben Collins
Date: Fri, 22 Mar 2013 11:39:20 -0400
> If your company had hardware going to production, you'd want it
> supported in mainline too, I suspect.
But never against the wishes of the author of the code.
This has firm and strict precedence, for example one of the
implementations b
On Mar 22, 2013, at 11:17 AM, David Miller wrote:
> From: Ben Collins
> Date: Fri, 22 Mar 2013 10:43:44 -0400
>
>> "For us" is a loose term, when it's more that we are attempting to
>> upstream code so our system is supported by a mainline kernel
>> instead of having one-off kernels.
>
> If th
From: Ben Collins
Date: Fri, 22 Mar 2013 10:43:44 -0400
> "For us" is a loose term, when it's more that we are attempting to
> upstream code so our system is supported by a mainline kernel
> instead of having one-off kernels.
If this other person doesn't want their code upstreams, it is absolute
On Fri, 2013-03-22 at 10:50 -0400, Ben Collins wrote:
>
> NETIF_F_LLTX_BIT, /* LockLess TX - deprecated. Please */
> /* do not use LLTX in new drivers */
Yes, but this is the current way to do that.
Unless you design a complete new l
On Mar 22, 2013, at 10:23 AM, Eric Dumazet wrote:
> On Wed, 2011-07-13 at 08:52 -0500, Andy Fleming wrote:
>> The QDisc code does a bunch of locking which is unnecessary if
>> you have hardware which handles all of the queueing. Add
>> support for this, and skip over all of the queueing code if
>
On Mar 22, 2013, at 9:11, "David Miller" wrote:
> From: Andy Fleming
> Date: Wed, 13 Jul 2011 08:52:04 -0500
>
>> The QDisc code does a bunch of locking which is unnecessary if
>> you have hardware which handles all of the queueing. Add
>> support for this, and skip over all of the queueing c
On Mar 22, 2013, at 10:33 AM, David Miller wrote:
> From: Fleming Andy-AFLEMING
> Date: Fri, 22 Mar 2013 14:31:50 +
>
>> It would appear one of our customers is attempting to upstream our
>> code for us. We are aware that this current solution is unacceptable
>> (which is why we have not su
From: Fleming Andy-AFLEMING
Date: Fri, 22 Mar 2013 14:31:50 +
> It would appear one of our customers is attempting to upstream our
> code for us. We are aware that this current solution is unacceptable
> (which is why we have not submitted it), and we are currently trying
> to develop a less
On Wed, 2011-07-13 at 08:52 -0500, Andy Fleming wrote:
> The QDisc code does a bunch of locking which is unnecessary if
> you have hardware which handles all of the queueing. Add
> support for this, and skip over all of the queueing code if
> the feature is enabled on a given device, which breaks Q
From: Andy Fleming
Date: Wed, 13 Jul 2011 08:52:04 -0500
> The QDisc code does a bunch of locking which is unnecessary if
> you have hardware which handles all of the queueing. Add
> support for this, and skip over all of the queueing code if
> the feature is enabled on a given device, which brea
The QDisc code does a bunch of locking which is unnecessary if
you have hardware which handles all of the queueing. Add
support for this, and skip over all of the queueing code if
the feature is enabled on a given device, which breaks QDisc
support on dpaa_eth, and also coopts the FCOE feature bit.
21 matches
Mail list logo
