3Com 3cr990 driver release

3Com 3cr990 driver release

[David Dillow]

Finally, after too many delays, I am pleased to announce the release of my
driver for 3Com's 3cr990 family of network cards.

This initial release is endian clean, tested on x86 and sparc64, and does
 - NAPI
 - Zerocopy Tx
 - TCP segmentation
 - Hardware VLAN accel

It does *not* do IPSEC crypto offload as of yet. I have a version for the 2.4
series of kernels, but it is an ugly, ugly kludge, and would be shot if seen
in public. I will be working on integrating the hardware with the IPSEC
support in 2.5.x.

There are a few issues with the firmware -- DMA to a 2 byte aligned address
hangs the firmware, so we cannot easily align the IP header, and the firmware
will always strip the VLAN tags on packet reception, regardless of our
desires. I hope to work with 3Com to resolve these issues.

The code is available via BK at
http://typhoon.bkbits.net/typhoon-2.4
http://typhoon.bkbits.net/typhoon-2.5

Diffstats:

typhoon-2.4:

 Documentation/Configure.help   |   18
 MAINTAINERS                    |    6
 drivers/net/Config.in          |    3
 drivers/net/Makefile           |    1
 drivers/net/typhoon-firmware.h | 4108 ++++++++++++++++++++++++++++++++++++
 drivers/net/typhoon.c          | 2505 ++++++++++++++++++++
 drivers/net/typhoon.h          |  613 ++++++
 include/linux/pci_ids.h        |    8
 8 files changed, 7262 insertions(+)


typhoon-2.5:

 MAINTAINERS                    |    6
 drivers/net/Kconfig            |   20
 drivers/net/Makefile           |    1
 drivers/net/Makefile.lib       |    1
 drivers/net/typhoon-firmware.h | 4108 ++++++++++++++++++++++++++++++++++++
 drivers/net/typhoon.c          | 2505 ++++++++++++++++++++
 drivers/net/typhoon.h          |  613 ++++++
 include/linux/pci_ids.h        |    8
 8 files changed, 7262 insertions(+)


I'd like to thank 3Com's engineers for finding me documentation and putting up
with my questions, and my project manager for navigating the bureaucracy so
that this work may see public use. I couldn't have received a better going
away present on my last day on the job.

Enjoy!
David Dillow
dillowd@y12.doe.gov (old)
dave@thedillows.org (new)

Re: 3Com 3cr990 driver release

[Jeff Garzik]

I know it was a long time coming :)

Thanks, queued for 2.4 and 2.5.

	Jeff

Re: 3Com 3cr990 driver release

[Alan Cox]

On Fri, 2003-02-14 at 07:50, David Dillow wrote:
> There are a few issues with the firmware -- DMA to a 2 byte aligned address
> hangs the firmware, so we cannot easily align the IP header, and the firmware
> will always strip the VLAN tags on packet reception, regardless of our
> desires. I hope to work with 3Com to resolve these issues.
> 
> The code is available via BK at
> http://typhoon.bkbits.net/typhoon-2.4
> http://typhoon.bkbits.net/typhoon-2.5

Would you care to make the patches available in a format those of us who
work on open source version control systems can use. Right now Mr McVoy
prohibits me from reviewing your patches.

Re: 3Com 3cr990 driver release

[Larry McVoy]

On Fri, Feb 14, 2003 at 02:33:30PM +0000, Alan Cox wrote:
> On Fri, 2003-02-14 at 07:50, David Dillow wrote:
> > There are a few issues with the firmware -- DMA to a 2 byte aligned address
> > hangs the firmware, so we cannot easily align the IP header, and the firmware
> > will always strip the VLAN tags on packet reception, regardless of our
> > desires. I hope to work with 3Com to resolve these issues.
> > 
> > The code is available via BK at
> > http://typhoon.bkbits.net/typhoon-2.4
> > http://typhoon.bkbits.net/typhoon-2.5
> 
> Would you care to make the patches available in a format those of us who
> work on open source version control systems can use. Right now Mr McVoy
> prohibits me from reviewing your patches.

That seems a bit extreme, Alan.  I don't recall prohibiting you from anything
of the kind.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: 3Com 3cr990 driver release

[Alan Cox]

On Fri, 2003-02-14 at 15:19, Larry McVoy wrote:
> > Would you care to make the patches available in a format those of us who
> > work on open source version control systems can use. Right now Mr McVoy
> > prohibits me from reviewing your patches.
> 
> That seems a bit extreme, Alan.  I don't recall prohibiting you from anything
> of the kind.

Since I work for a company who works on competing version control products I'm
not allowed to use bitkeeper. Since his patches are only in bitkeeper format
I can't read them.

I'd like to read them so I asked for them in a open format.

Alan

Re: 3Com 3cr990 driver release

[Larry McVoy]

On Fri, Feb 14, 2003 at 04:54:01PM +0000, Alan Cox wrote:
> On Fri, 2003-02-14 at 15:19, Larry McVoy wrote:
> > > Would you care to make the patches available in a format those of us who
> > > work on open source version control systems can use. Right now Mr McVoy
> > > prohibits me from reviewing your patches.
> > 
> > That seems a bit extreme, Alan.  I don't recall prohibiting you from anything
> > of the kind.
> 
> Since I work for a company who works on competing version control products I'm
> not allowed to use bitkeeper. Since his patches are only in bitkeeper format
> I can't read them.

Sure you can, unless your objection extends to getting at data which is in
BK over the web.  http://typhoon.bkbits.net:8080/typhoon-2.4/patch@+

And you have options beyond that.  Perhaps it has escaped your notice that
Dave M and others who are also employed by Red Hat are (happily?) using
BK and we haven't kicked up a fuss.

I tend to doubt that you really want to use BK, you seem to have strong
feelings about it, but if you do and you want to be sure that you can,
that's an easily solved problem.  And if you don't want to be special
cased, which is understandable, then you can have a manager from Red Hat
talk to me and we'll work it out just like we're working it out with other
companies.

That goes for any other kernel developer who feels that they are in
a gray area.  No, we're not going to make an exception if you are 
actively contributing to a different SCM system, that's where we draw
the line.  But the license cast a wide net by saying "you or anyone in
your company" so we're willing to work out.  The goal is to support 
kernel development, and there is another unfortunate constraint of 
not shooting ourselves in the foot.  As long as we can do both, we 
will.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: 3Com 3cr990 driver release

[Alan Cox]

On Fri, 2003-02-14 at 16:09, Larry McVoy wrote:
> > Since I work for a company who works on competing version control products I'm
> > not allowed to use bitkeeper. Since his patches are only in bitkeeper format
> > I can't read them.
> 
> Sure you can, unless your objection extends to getting at data which is in
> BK over the web.  http://typhoon.bkbits.net:8080/typhoon-2.4/patch@+
> 
> And you have options beyond that.  Perhaps it has escaped your notice that
> Dave M and others who are also employed by Red Hat are (happily?) using
> BK and we haven't kicked up a fuss.

Since Red Hat works on CVS I wonder if they are breaking the license or
not. However thats not relevant right now. If I get stuff in .doc format
that I can't read I ask people to resend it in a format I can, ditto
bitkeeper or any other randomly weird VC file.

And no I don't want to use bitkeeper any more, your ever changing
licenses and removals of more and more rights have reminded me why 
many proprietary vendors just cannot be trusted and why format lockin
is so dangerous.

You are turning a simple "can I have that in a format I can read" into 
yet another epic bitkeeper flame war.

Alan

Re: 3Com 3cr990 driver release

[Larry McVoy]

On Fri, Feb 14, 2003 at 05:23:35PM +0000, Alan Cox wrote:
> And no I don't want to use bitkeeper any more, your ever changing
> licenses and removals of more and more rights have reminded me why 
> many proprietary vendors just cannot be trusted and why format lockin
> is so dangerous.

The license hasn't changed in almost a year, so perhaps you'd care to 
back up this "ever changing licenses" statement with some data?  Stop
spreading FUD, Alan, it's beneath you.  I could just as easily attack
Red Hat for getting patents, do you see me doing that?  

And just what rights have we removed?  Since the license hasn't changed,
it's sort of hard to say that the rights have changed.  More FUD.

And what format lockin?  It's an open format, GNU CSSC reads and writes
it just fine, and we've made a point over the years of telling them each
time we change something so that they can continue to read/write our
files.  More FUD.

> You are turning a simple "can I have that in a format I can read" into 
> yet another epic bitkeeper flame war.

No, I'm countering a pile of pathetic FUD from someone who has no
business spreading it.  I've taken a lot of crap in return for helping
the kernel effort and I'm sick of it.  I haven't noticed you, Alan,
taking a half decade off to code up an SCM system good enough for
Linus to use.  Without the benefit of having one to copy, by the way.
When you've done that you are welcome to critize how I went about it.
Until then, stop your whining.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: 3Com 3cr990 driver release

[Tomas Szepe]

> [lm@bitmover.com]
> 
> No, I'm countering a pile of pathetic FUD from someone who has no
> business spreading it.  I've taken a lot of crap in return for helping
> the kernel effort and I'm sick of it.

Look, I don't want this to sound harsh, but what did you expect?
What you have arranged for with Linus[1] using BK[2] is so contro-
versial that you must have expected to get A LOT of shit thrown at
you in the process, regardless of how much good/evil your work would
have caused.  I'd expect that by now you would have long learnt
to completely ignore all the nonconstructive posts in the never-ending
BK threads and only focus on resolving technical problems.

[1] As one of the few symbols of the open source world.
[2] As proprietary software with lots of strings attached.

> I haven't noticed you, Alan, taking a half decade off to code up an SCM
> system good enough for Linus to use.

Alan's qualities are elsewhere, I'm sure you've noticed.

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: 3Com 3cr990 driver release

[Larry McVoy]

On Fri, Feb 14, 2003 at 06:04:20PM +0100, Tomas Szepe wrote:
> > [lm@bitmover.com]
> > 
> > No, I'm countering a pile of pathetic FUD from someone who has no
> > business spreading it.  I've taken a lot of crap in return for helping
> > the kernel effort and I'm sick of it.
> 
> Look, I don't want this to sound harsh, but what did you expect?

I had the naive expectation that having been around in the kernel
community for a long time, and having never done anything except attempt
to continue to help, that maybe people would wait until some wrong took
place before starting with the mud slinging.

Silly me, what was I thinking?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: 3Com 3cr990 driver release

[Roman Zippel]

Hi,

On Fri, 14 Feb 2003, Larry McVoy wrote:

> And what format lockin?  It's an open format, GNU CSSC reads and writes
> it just fine, and we've made a point over the years of telling them each
> time we change something so that they can continue to read/write our
> files.  More FUD.

Are these changes/extensions documented somewhere or is a patch available?
My version of cssc certainly has a few problems, without patching it's 
very noisy.

bye, Roman

Re: 3Com 3cr990 driver release

[Larry McVoy]

On Fri, Feb 14, 2003 at 07:40:32PM +0100, Roman Zippel wrote:
> Hi,
> 
> On Fri, 14 Feb 2003, Larry McVoy wrote:
> 
> > And what format lockin?  It's an open format, GNU CSSC reads and writes
> > it just fine, and we've made a point over the years of telling them each
> > time we change something so that they can continue to read/write our
> > files.  More FUD.
> 
> Are these changes/extensions documented somewhere or is a patch available?
> My version of cssc certainly has a few problems, without patching it's 
> very noisy.

The only change is to accept ^AHxxxxx as well as ^Ahxxxxx as the per file
checksum.  I'm almost positive that someone posted a patch to the kernel
which made CSSC like BK files.

If the BK files are compressed, you have to uncompress them first and you
can't use gunzip to do so, you have to use BK.  You could teach CSSC to
read our compressed files if you like, there is no secret to how we do 
that, the top part of the file containing the graph is uncompressed and
the rest is compressed, so you have to tickle the code into being able to
start uncompressing at an offset other than 0.

The only other difference I know of is that we support files without newlines
at the end of the file and CSSC doesn't (and I don't blame them, it is 
dramatically more difficult than you might think at first glance).
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: 3Com 3cr990 driver release

[Roman Zippel]

Hi,

On Fri, 14 Feb 2003, Larry McVoy wrote:

> > Are these changes/extensions documented somewhere or is a patch available?
> > My version of cssc certainly has a few problems, without patching it's 
> > very noisy.
> 
> The only change is to accept ^AHxxxxx as well as ^Ahxxxxx as the per file
> checksum.  I'm almost positive that someone posted a patch to the kernel
> which made CSSC like BK files.

cssc complains about ^Ac[C-Z] lines and dies at ^Af x lines.

bye, Roman

Re: 3Com 3cr990 driver release

[Henning P. Schmiedehausen]

Larry McVoy <lm@bitmover.com> writes:

>taking a half decade off to code up an SCM system good enough for
>Linus to use.  Without the benefit of having one to copy, by the way.

Using this statement over and over doesn't make it more true.

Linus stated in public that he was/is unhappy with CVS. Without
Bitkeeper he might use Subversion today. But by using Bitkeeper he
made it possible that you and your company started using him as your
posterboy for the "SCM good enough for Linus Torvalds to use". This is
IMHO not correct. BK is just "the first SCM which came along and was
good enough for Linus Torvalds to use it".

I do remember Linus saying that he wants to try out BitKeeper for the
2.5 development tree and if it does not work out, switch to something
else in the 2.6, 2.7... cycle.

The rift that the whole BitKeeper/BitMover stuff has opened in the
kernel developer community IMHO justifies such a step forward . I'd
like to see SVN to be used as an alternative tool. Not because it is
better (it probably is not, but I haven't had a chance to try out BK
because I don't qualify for the free license) than BK but because it
has no strings attached to its usage.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

Re: 3Com 3cr990 driver release

[Alan Cox]

On Fri, 2003-02-14 at 16:09, Larry McVoy wrote:
> Sure you can, unless your objection extends to getting at data which is in
> BK over the web.  http://typhoon.bkbits.net:8080/typhoon-2.4/patch@+
> 

Patch isnt noted for its handling of pretty blue html btw

Re: 3Com 3cr990 driver release

[Steven Cole]

On Fri, 2003-02-14 at 10:28, Alan Cox wrote:
> On Fri, 2003-02-14 at 16:09, Larry McVoy wrote:
> > Sure you can, unless your objection extends to getting at data which is in
> > BK over the web.  http://typhoon.bkbits.net:8080/typhoon-2.4/patch@+
> > 
> 
> Patch isnt noted for its handling of pretty blue html btw
> 

Larry,

A possible solution to this is to provide the equivalent of the
"Download Message Raw" link which marc.theaimsgroup.com provides, e.g.
here: http://marc.theaimsgroup.com/?l=linux-net&m=104524036019392&q=raw

BTW, thanks for creating and providing BK.  It seems to me that the
positive contributions you've made far out-weigh the negative aspects
which some perceive.

Steven

Re: 3Com 3cr990 driver release

[David Dillow]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

Alan Cox wrote:
> 
> On Fri, 2003-02-14 at 07:50, David Dillow wrote:
> > There are a few issues with the firmware -- DMA to a 2 byte aligned address
> > hangs the firmware, so we cannot easily align the IP header, and the firmware
> > will always strip the VLAN tags on packet reception, regardless of our
> > desires. I hope to work with 3Com to resolve these issues.
> >
> > The code is available via BK at
> > http://typhoon.bkbits.net/typhoon-2.4
> > http://typhoon.bkbits.net/typhoon-2.5
> 
> Would you care to make the patches available in a format those of us who
> work on open source version control systems can use. Right now Mr McVoy
> prohibits me from reviewing your patches.

Unfortunately, the only way I can do this right now is to send them as a
compressed attachment -- the only avenue I have for hosting is currently
experiencing "network difficulties." 

typhoon-driver.patch is the actual driver, and applies to 2.4 and 2.5
The other patches put it in the build system, and should apply to recent
kernels.

Sorry to spam the lists,
Dave Dillow
dillowd@y12.doe.gov (old)
dave@thedillows.org (new)

[-- Attachment #2: typhoon-patches.tar.bz2 --]
[-- Type: application/octet-stream, Size: 62836 bytes --]

Re: 3Com 3cr990 driver release

[Alan Cox]

On Fri, 2003-02-14 at 17:20, David Dillow wrote:
> Unfortunately, the only way I can do this right now is to send them as a
> compressed attachment -- the only avenue I have for hosting is currently
> experiencing "network difficulties." 
> 
> typhoon-driver.patch is the actual driver, and applies to 2.4 and 2.5
> The other patches put it in the build system, and should apply to recent
> kernels.

Thanks. I speak attachments just fine 8)