linux-kernel - Re: [PATCH] net: Add support for handling queueing in hardware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Mar 2013 11:53:54 -0400
From:	Ben Collins <benmcollins13@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	afleming@...escale.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] net: Add support for handling queueing in hardware

On Mar 22, 2013, at 11:41 AM, David Miller <davem@...emloft.net> wrote:

> From: Ben Collins <benmcollins13@...il.com>
> 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 block layer encryption was not wanted to be merged by
> the author, and Linus reverted it.
> 
> So if the person who wrote the code doesn't want it upstream, you can't
> bypass them against their wishes, ever.  It's their code not your's.

They never made such a statement. The commit (which is publicly available in Freescale's git repo) makes no mention of it being "good enough for our SDK, but don't send upstream". Freescale wants this upstream, but doesn't have the resources because they are embedded focused and gear more toward SDKs to support their SoCs (currently that means a 3.0.x kernel).

Don't accuse me of something I didn't do. 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.

We are a hardware company. We've been provided with a driver for the platform we designed by the SoC vendor. It's GPL licensed. We've attempted to get this done by them, but they haven't been able to, so we are exercising prudence and making sure our platform is supported in mainline. I don't see where that's any different than tons of other patches that go into the kernel.

If it makes everyone feel better, I'll limit attribution in the patches to just an Originally-By: line.

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu    : http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/