2.3.51 tulip broken

[Jeff Garzik]

Donald Becker wrote:
> A quick search of the two very active Tulip mailing lists reveals that you
> have contributed nothing until this year.  Apparently you were not even a
> subscriber until then, and know nothing about the very open way development
> has been done.  Yet you willing throw around pejorative phrases like
> "cathedral style" -- a hot button in this community.

I see only the end results, and especially the cathedral style of
development as applied to your pci-netif changes.

Let's look at your FTP site.

Stable tulip.c -- last updated Dec 28, 1999.
Stable eepro100.c -- Last updated Aug, 1999.
All other stable drivers are older than this.

Test 3c59x.c -- last updated Dec 15, 1999.
Test eepro100.c -- last updated Sep 1999.
test winbond -- last updated Sep 1999.
test via-rhine -- last updated Aug 1999.
All other test drivers are older than this.

(pci-netif stuff)
2.3 rtl8139.c -- last updated Oct 1999.
2.3 epic100.c -- last updated Oct 1999.
All other 2.3 drivers last updated in Sep 1999.

In short, none of your drivers appear up to date, especially with
respect to the bugs I see being reported on the eepro100, rtl8139, and
other lists.  Stable tulip seems to be the one driver updated recently
-- and that was over three months ago.


> For those not interested what superficially appears to be a kernel power
> grab, [...]

I'm sorry things appear that way to you or others.

Let's look at the facts:

* The kernel network drivers are the most widely used Linux network
drivers.  They have been UNMAINTAINED for well over a year.

* You disappeared for many months, designing, implementing, and testing
a network driver interface.  (this is not a problem in and of itself)

* Once this network interface appeared (note - no announcement on
linux-kernel), you ignored ALL discussion and bug reports.

* I personally sent you three private e-mails over an 8-month period, in
which I described the problem of divergent network drivers, very
courteously, and requested that you work with me and other kernel
developers to resolve this situation.  No response.

* Linus and DaveM have both described this problem as well, publicly on
linux-kernel and privately as well.  You ignored them too.

* You do not participate in kernel development.


As a result of all this, I felt it was clear that you were not going to
resolve the situation by yourself.  Thus, I began merging your work and
others into the kernel.  You might see that as a power grab, I see it as
filling a sorely needed spot in Linux kernel development.

I would rather NOT maintain any network drivers at all -- less time
consumed for me -- but noone else has stepped up to the plate.


>   1) Should the kernel source code interfaces, for well-understood
>      interfaces, be stable?  (We are solidly committed not having a binary
>      interface, so bringing that up is a red herring.)

The standard policy is to provide a stable interface for each stable
series.


>   2a) Given that development kernels are frequently unstable in some
>     unexpected way, is is reasonable force testing of driver changes
>     combined with unknown other changes?

In the general case you have a point.  And for many driver developers,
waiting until new stable versions are released (2.2, 2.4, ...) is a good
tact to follow.

However, for the specific case, Donald, you must realize that your
drivers are a special case:  your drivers comprise the bulk of the most
popular networking drivers.  It is unreasonable for a large part of the
kernel network drivers to be broken during the development series.

Yes, I fully realize this puts pressures on you to closely follow kernel
development and keep your drivers updated for the latest development
series.  I wish it were not so, for this has led to the divergence of
the kernel and Becker net drivers.

To me it seems clear that like "Linus overload", there are clearly more
tasks to be done in network drivers than you can handle.  Bugs are not
getting fixed.  Feedback from kernel developers is ignored.  Changes in
the kernel are ignored.


>   2b) Given that the kernel continues to exponentially increasing in size,
>     should all development go through the latest development kernel?

The kernel core is not exponentially increasing in size.  It's just that
new drivers are added all the time.  So the first part of this statement
is really a non-issue.  It's just download time.

As for the second part of your sentence here, no, all development need
not go through the latest development kernel.

BUT again -- your drivers are a special case.  The situation, at least
for the
2.3 series, was to go ahead and hack on the drivers in the kernel tree
and get them working, or wait many months without network access(!!)
until you(Donald) arrived at a 2.3 network driver update which satisfied
Linus and other kernel developers.

That simply does not scale.


> I feel the network driver interface from 1.2.* through 2.2.* is the cleanest
> interface in the kernel.  It's possible to add most new drivers to the
> kernel without modifying or recompiling the kernel source.  I like to think
> that I influenced the clean design.

Yes, but change cannot be avoided forever.

Your drivers do not support SMP well at all, for example, because of
your current policy of supporting 2.0-style drivers on any kernel.  (as
I noted, I believe the best method is to support bleeding edge drivers
on older kernels, rather than the other way around)


> Compare that to the filesystem code, which requires that the kernel be
> reconfigured and recompiled if you wish to add a new filesystem.

This is not the case during a stable kernel version.  If the VFS changes
during 2.4.0 kernel series, without a REALLY GOOD reason, I'm sure
people will be burning Al Viro and Linus in effigy ;-) ;-)


> Or a new
> block driver, where there is a similar situation with block.h.  Both the VFS
> layer and the block driver interface should be very well understood, but the
> nicely designed interfaces were quickly corrupted with ugly hacks.

I'm sure Al Viro would have a bone to pick with that...


> I think the continued viability of a monolithic, single-point kernel source
> tree should be questioned.  The average *compressed* patch size for the 51
> kernel patches since 2.3.1 is over 346KB, totaling just under 18MB.  When
> uncompressed, that's over 1MB per patch, far more than it's possible for
> anyone to reasonably review.

No one is asking you to review the entire kernel source.  Just follow
current kernel developments!


> The usual justification for this scale of change is that only the developers
> should be using the development source tree.  But the "official" advice to
> anyone with device problems, frequently repeated on the kernel mailing list,
> is to run the latest development kernel.

Incorrect.  The official advice is to get the latest stable pre-release
kernel, if the latest stable kernel does not meet your needs.

This is just a guess, but you are probably judging from my own actions,
which stem from the fact that I hack on 2.3.x and not on 2.2.x kernels. 
Alan Cox regularly accepts changes to the 2.2.x kernels which fix bugs
and handle device problems.  That is the way kernel development works --
bug fixes go into stable series, new development (and hopefully bug
fixes!!) go into the development series.


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