[tulip] Most ethernets record?

[Ben Greear]

"David S. Miller" wrote:
> 
> Ben Greear writes:
>  > Yes, there seems to be a major pissing contest between who can
>  > be the more hard-headed about this kind of thing.  The end
>  > result, unfortunately, is broken drivers that are making my
>  > life, as well as many others, a complete pain in the arse
>  > when it comes to doing any type of high-performance networking
>  > on Linux.  We have all these great routing/firewalling technologies,
>  > but try finding a NIC/driver that can hold up under the strain!!!
> 
> There is an official channel to help the maintainers work
> on fixing the problems that you find, and in fact the current
> 2.4.x tulip maintainer is quite good a being responsive.
> 
> Talk to Jeff Garzik about 2.4.x tulip problems if you haven't
> done this already.

Yes, he is one of the most responsive developers I've met, and
I have talked with him.  However, for whatever reason, the problem(s)
do not get fixed.  It couldn't hurt to have Becker back on board
the modern kernel.

Donald, if you are reading this, what kind of driver architecture
compromise can we reach that can bridge your driver work with the
new kernel?  If the resources remain split between 2.2 and 2.4, both
will suffer: 2.2 will fall behind all other areas, so your drivers
will be come irrelevant, and 2.4 will continue to have marginal drivers,
which threatens to make all of Linux suffer.

> This is comparing apples to oranges.  You want to add a complete
> subsystem to the kernel.  This is different than adding a driver.
> 
> When you add a subsystem to the networking, which I maintain, sure
> there are a lot of hurdles.  But look at the bluetooth stuff, that
> person did all the work I asked of them to make the patches acceptable
> to me, and then I simply put them in.

Well, the last thing I remember hearing from you was that the
VLAN code would go into 2.5, if ever.  There was no specific
gripe list or suggestions on how to make it more palatable to you,
just 'NO'.  How the hell am I supposed to figure out how to
change things to fit your particular taste!
 
> It's a matter of taking responsibility and doing the grudge work to
> get the patch in.  Sometimes like Linus I have to dump mails because I
> simply get so many.  You have to retransmit and you have to do the
> work to convince me to put in your changes, not the other way around.
> If you don't want to put forth the effort of retransmitting,
> explaining your changes clearly, and fixing up anything I request,
> then you really don't care about your patch.
> 
> Maybe I won't even like how you do the VLAN stuff at all.  And if I do
> hate it, you have to find a way to make it acceptable to me and deal
> with the things I don't like about your changes.  It's called
> filtering and it tends to keep crap from accumulating in the tree.

Maybe the filter is too tight in your area, and maybe that is choking
off both module writers such as myself as well as other coders
more interested in drivers.

> 
> And don't take it personally, this is what everyone has to go through
> who wants to install major changes.  It doesn't matter if you are
> going through Linus, myself, or some other maintainer.

I find it hard to not take it personally.  The code is technically
correct in that it seems to cause no harm to existing users, and it
actively provides the 802.1Q VLAN feature that some people like.  It
has been stable for a year now (2.2 and 2.4).  Every piece of VLAN code has #ifdef's
around it, so it will not impact the kernel at all if it is not selected
for inclusion.  The only reasons left for not including
it must relate to style of the code and/or personal dislike of the
entire feature by yourself.  Now add to it the fact that I have never
even been notified of what the reasons for exclusions are, and you
have a good recipe for disgruntlement.  I'm used to dealing with this
kind of beauracracy at the day job, but it's not fun to find it here
too...


-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear