2.3.51 tulip broken

[David Ford]

Jeff Garzik wrote:

> > That work took several months to complete, during which time incremental
> > versons of many driver were readily available using the frequently-changing
> > interface.
>
> This a key problem.  You do closed source development with public code
> drops after many months.  That is not the Linux kernel way.  That is not
> the Internet way.  The world now moves in Internet time.

Ahem.  No.  There are dozens of incremental code releases all publicly available on
the maintainer's site.


> Further, your months of CLOSED SOURCE work and testing produced buggy
> code which completely ignores kernel infrastructure.

His 'buggy' code resulted in -more- operational cards than the convoluted v86 that
stayed in the kernel for an unbearable time.  I got so tired of copying Donald's
tulip.c into the tree everytime I put a new kernel up that I made a script.  Even
after much deliberation on l-k.  The l-k copy of tulip.c was never updated from
Donald's site because "the patch was too big" until there was such a gnashing of
teeth that Alan allowed it.

A great many of us had to use the 'buggy' version from Donald because his worked,
the kernel version didn't.


> Correct on the last point.  And re-read the thread:  I did not need
> to have written any hot-swap drivers to be able to point out all the
> MMIO-related deficiencies in your code.  Deficiencies which could
> have easily been corrected had you PUBLICLY discussed your changes,
> instead of doing closed source development.

Tulip development is such a huge issue that it has it's own list and discussion of
the drivers is encouraged there.  Same goes for cards like the eepro.  There has
been a -lot- of public discussion regarding a -lot- of the changes.


> The Linux kernel is incrementally developed.  That is how things work in
> the open source world.  If you have a better design, you cannot simply
> appear one day and say "mine is better, take it or leave it."

And the open source world has more than one place for work to get done.  Note the
USB crew does the majority of their work -and- discussion elsewhere.  Combining the
traffic for all the lists of all the developers onto l-k would make keeping up with
l-k very unbearable.


> > To you such an interface change is a minor tweak that can be with an
> > automated search-and-hack.  What takes you only a minute per file to change
> > might take the developer hours over the next few months to deal with to
> > integrate with testing.  This is especially true when Linus insists that all
> > traces of 2.2 support be expunged in the 2.3 drivers.
>
> Did you ever stop and consider that implementing 2.3 drivers with a
> backward compatibility layer for 2.2 and 2.0 kernels is more flexible,
> and also easier to integrate into the mainline kernel?

What's the point of a compatibility layer when Linus said get rid of 2.2 support?


> The Linux kernel user base is the largest test base in the world.  As
> Linus has pointed out to you, the people who use the drivers from
> your Web site are a self-selected test group.  If a Linus tree driver
> works by default for a user, you never ever hear from them.

We've gone over this again and again.  We simply aren't going to culminate all the
development efforts onto one list and one source tree.  Right now we have dozens of
different trees for the linux kernel.  CVS, Alan's, Ingo's...etc.  It makes more
sense when you're trying to eliminate bugs to constrain change to a well known set.

It's all nice and fine that you're trying to make a good thing with the tulip
driver.  But alienating the guy who probably knows the most about the chipsets by
far isn't a good thing for you or us.  I appreciate your effort and I don't fault
your effort.  I do dislike the attitude wrt Donald and that's the extent of my
angst.  Unfortunately, all tulip stuff I have fails all over the place with the
listed faults.  I can't now use the tulip code in the kernel, nor can I easily
patch Donald's code in due to the variance.  I'm forced to pull all my tulips out
and put other cards in.

-d


-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org