Our Gigabit ethernet driver was written as a GPL'ed open source driver to
support various 2.2.x and 2.4.x Linux kernels. The primary objectives were
to support Intel
i386 and ia64 platforms and provide high performance especially in server
type
applications. The driver was also written in a way that proprietary
information about the hardware would not be unnecessarily disclosed. This is
necessary to protect our intellectual property and to keep a competitive
edge in the highly competitive Gigabit NIC marketplace.
We don't claim to be Linux experts but no one knows about our hardware more
than we do. At this point, we cannot support the Linux open source community
to write their
own driver. Doing so would require us to disclose too much proprietary
information about
our hardware and put us in a competitive disadvantage in the Gigabit
marketplace. We stronly
believe our driver is solid and provides high performance for our customers.
In one
benchmark test, we've achieved better than 1.8 Gigabit total throughput
using jumbo frames. While
our emphasis has been on Intel i386 and ia64 platforms, our recent versions
of the driver are also
known to work on PowerPC, Sparc, and alpha platforms. While we welcome any
constructive suggestions on improving our driver in anyway, we want to point
out that there are
different styles to writing a device driver, not just the style advocated by
a couple of
arrogant Linux people.
Here more details comments to the Dave Miller's email on Broadcom Driver.
> >It is meant to replace Broadcom's driver because frankly their driver
> > is junk and would never be accepted into the tree. For an example of
> > why their driver is junk, note that the resulting object file from our
> > driver is less than half the size of Broadcom's. That kind of bloat
> > is simply unacceptable.
[BRCM] Our driver is 117K, Intel's driver is 82K, the Altima driver is 82K.
It has
a lot of features and carries all backward compatible for all chips
including
firmware.
> > Next, Broadcom's driver is still way
> > non-portable, ioremap() pointers are still dereferenced directly among
> > other things.
[BRCM] The driver was changed to use readl/writel macro in version 2.0.31 on
12/14/01 when we started testing on other non-Intel platforms and added
big-endian support. Prior to that we only supported Intel platforms and
direct access is not a problem on Intel platforms.
> > Finally, their driver is just plain buggy, they have
> > code which tries to use page_address() on pages which are potentially
> > in highmem and that is guarenteed to oops.
[BRCM] It is true that the driver uses page_address() in one subroutine that
is
used to workaround a problem on the very early 5700 chip. But this routine
is not used at all, it was there intially to support early rev of the
silicon.
It was removed in later version of the Broadcom driver.
Regards,
Timothy Ngo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/