netdev - Re: [PATCH] Intel IXP4xx network drivers v.2

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:	Wed, 09 May 2007 10:22:24 -0400
From:	David Acker <dacker@...net.com>
To:	Lennert Buytenhek <buytenh@...tstofly.org>
CC:	Marcus Better <marcus@...ter.se>,
	linux-arm-kernel@...ts.arm.linux.org.uk, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS

Lennert Buytenhek wrote:
> The people who need a LE network driver can use Christian's driver,
> as Christian's driver works in LE just fine.  The people who care
> about LE support can add LE support to the driver that Krzysztof wrote.
> 
> I don't think that not supporting LE is a reason not to merge
> Krzysztof's driver.  Don't make supporting LE systems Krzysztof's
> problem.
> 
> Krzysztof has written an excellent driver, and while it would be 100%
> Debian style to reject his driver just because it doesn't support LE[*],
> thankfully, Linux is not Debian.  Please don't turn Linux into Debian.

I am using the ixp425 on the avila from gateworks.  It only has 16 MB of 
  flash built in.  We needed to squeeze a production and a failsafe 
linux inside that so debian was not an option.  I found intel's original 
drivers horrible to read, maintain, and use.  We are using Cristian's 
driver (rev 0.2.1) and are preparing to go to his latest for the crypto 
support.  I only had one bug in 0.2.1, which is fixed in later versions. 
  I would love to see mail line support for this device, including the 
ethernet ports and the crypto capabilities.

We run in big endian despite the extra difficulty in toolset setup and 
finding lots of brain0-damaged-designed-for-x86 code.  We already can 
use up the CPU when we have the mini-pci slots populated with 802.11g 
radios and the ethernet port in use.  Swapping packets would kill us. 
Never mind if we do any kind of software based crypto!  For those of us 
in the embedded space, performance matters.

Big endian is the natural setup for the NPEs on this hardware according 
to the intel documentation.  Please don't stop this driver from moving 
forward so that a few folks can run their hardware in slow mode.

-Ack
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html