2.3.51 tulip broken

[Jeff Garzik]

On Thu, 16 Mar 2000, Jim Morris wrote:
> If you've followed the tulip driver development at all, you would know
> the reasons that the kernel drivers and some of Donald's ethernet
> drivers have "diverged".

Correct.  Kernel infrastructure is developed, and Donald ignores that
infrastructure.


> I have to side with Donald on a lot of the
> reasons too.  Basically, if he is writing a driver, and want to maintain
> using a specific structure, that should be his perogative.  And I feel
> that he ought to be able to send something like a complete copy of
> tulip.c, rather than small incremental patches, if he wants too.

Donald does not work with other kernel developers when creating his
driver infrastructure.  He simply appears after many months of
development and says "here it is, take it or leave it."

There was no discussion at all of his new 2.3 PCI infrastructure until I
posted my own -- at which point he pipes up.  The linux-kernel
discussion of his and my infrastructure ensued, but he would not
consider any changes at all.  "it's tested, it doesn't need to change"

That is a shitty attitude, especially when his infrastructure code has
known and obvious bugs.


> In
> this case, it is Linus who insists on small, incremental patch
> submission - and that isn't how Donald is setup to work.

Um, it is Linus source tree.

The idea is that you work with Linus and the other kernel developers,
DISCUSS your changes in an open medium, and reach a happy solution which
satisfies all.  Donald does not do this.

We cannot afford to wait many months, with broken network drivers, while
Donald does his thing.


> Think of it this way:  it comes down to semantics.  Are drivers like
> tulip.c standalone development projects, or kernel development?  I know
> you will probably say kernel.  But in reality, with the use of modules,
> that is not necessarily true. The driver runs as a kernel task - but
> doesn't really have to be part of the kernel source tree, when you get
> down to it.

The kernel is not static.  Drivers outside the source tree are fine, as
long as they track current kernel changes.  Donald's driver do not do
this [correctly, at any rate].


> When you get down to it, the Linux source tree is so darned big these
> days because of all the esoteric device driver support.  In some ways it
> would be nice if there were two trees: a kernel tree, and a device
> driver tree! ;-)

Hey, I agree....   as long as it is one big-ass driver package which
tracks the core kernel source.  Otherwise you wind up with broken
drivers which do not work well with other drivers.

An example:  Donald's network infrastructure for 2.3, pci-netif, handles
resource allocation very poorly.  If you are using a kernel with other
drivers AND his pci-netif drivers, resources can be double-allocated, or
a driver might not load due to an incorrectly-registered resource.


> > I never claimed to be perfect but at least I am trying to fix some
> > of the the bit-rotten, UNMAINTAINED net driver code currently in
> > the kernel.
> 
> Again - those drivers in the kernel had been modified and patched by
> various people over the years, via patches sent in to Linus.  However,
> those patches were never sent in to Donald - the maintainer of the
> original driver. What do you expect him to do?  I.e. he's chugging a
> long on developing a handy-dandy new version of tulip.c or whatever, and
> the one in the released kernel diverges from it because of patches he
> doesn't know about....  is he supposed to reverse engineer his own
> device driver, to get up to date?

The kernel diverges from Donald's code because it gets more widely
tested and used than code on his web site.  People who download and use
his drivers are a small, self-selected group of users compared to those
who use the drivers in the standard kernel.

	Jeff





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