2.3.51 tulip broken

[Jeff Garzik]

David Ford wrote:
> 
> 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.

Last updated in Oct '99 or September '99 is not what I call frequent
updates.


> > 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.

If there are bugs in the current 2.2.x kernel series, file a bug
report.  (see REPORTING-BUGS in the kernel source tree)  I am sure there
are things that need to be migrated over from Donald's drivers.

As has been pointed out many times, change management in the stable
series is incredibly important.  You simply cannot blanketly update a
popular driver like tulip, you must incrementally update it, so that
changes can be evaluated carefully.  Donald is not perfect, and his
newer drivers do not work at all for some people.


> > 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.

Sure discussion occurs.  I don't see frequent updates appearing on
Donald's web site, nor do I see discussion of Donald's net driver core
changes on any mailing list [except when I flame him of course].


> > > 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 compatibility layer exists only for older kernels, which would
obviously need the support in order to run 2.3 drivers.  the compat
layer would be a no-op on the current kernel.

> 
> > 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.

You miss my point.

If changes are not regularly pushed out to the Linus tree, then you miss
important bug reports.  The people on linux-tulip, and the people who
use the driver's on Donald's web site, are SELF-SELECTED, and represent
the minority of all Tulip users.  This is not adequate enough testing to
ensure that a massive update will be bug-free for the users at large.

Donald lets changes build and build into one massive update, a "take it
or leave it" update.  If Alan accepts the update, then you take the good
with the bad.  Donald's massive updates have been BUGGY for some, great
for others.  Since his updates are KNOWN TO BE BUGGY for some cases, the
choice has been to not update the kernel driver, or update it piecemeal
with feedback from individual hackers and testers.

	Jeff




-- 
Jeff Garzik              | My to-do list is a function
Building 1024            | which approaches infinity.
MandrakeSoft, Inc.       |
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org