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
20 matches
Mail list logo
