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]

Message-ID: <20130323191023.GB22005@roeck-us.net>
Date:	Sat, 23 Mar 2013 12:10:23 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Theodore Ts'o <tytso@....edu>,
	Ben Collins <benmcollins13@...il.com>,
	David Miller <davem@...emloft.net>, afleming@...escale.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] net: Add support for handling queueing in hardware

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 they will drop use
> of their hardware in future products unless they get their !@#@S
> drivers upstream, I'd bet they'd change their engineering priorities
> so they would work on it, instead of foisting this work on their
> customers.
> 
I would love to be in that position. However, the decision to choose
a specific chip is not always coordinated with those who have to provide
the software to run on those chips.

> I've seen this work in enterprise computing, where the RFP had
> requirements for upstream drivers (i.e., if you want your 10gig
> ethernet NIC to be used in HP or IBM's servers, get the darned thing
> upstream!).  The trick is making it clear that selection of components
> depends not just on an OSS driver, but an OSS driver which has been
> accepted upstream (which also helps from a quality-of-code
> requirement).
> 
> I've been waiting for this to start happening in the consumer
> electronics/embedded world, but it's been slow coming,
> unfortunately....
> 
The same applies to vendors of non-consumer network devices, unfortunately.

Guenter
--
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/