2.3.51 tulip broken

[Donald Becker]

On Fri, 17 Mar 2000, Jeff Garzik wrote:
> David Ford wrote:
> > Please explain how his code development is closed source?  This is totally BS
> > and you know it.  All the code is available, all the list discussion is
> > available, and patches and requests are accepted all the time.
...
> Donald's development is not open AT ALL.
...
> It is classic cathedral style of development.  Read Eric Raymond's paper
> on why the bazaar method is far, far superior.  The Linux kernel is the
> bazaar method, and this is the central conflict which forced the kernel
> and Donald drivers to diverge.

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.

For those not interested what superficially appears to be a kernel power
grab, there are issue underlying all of what appears to be a personal
conflict.

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

  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?

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

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.

Compare that to the filesystem code, which requires that the kernel be
reconfigured and recompiled if you wish to add a new filesystem.  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 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.

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.

Donald Becker
Scyld Computing Corporation, becker@scyld.com

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