David Ford wrote:
>
> Jeff Garzik wrote:
>
> > Correct. Kernel infrastructure is developed, and Donald ignores that
> > infrastructure.
>
> Hmmmm. No.
hmmm, yes. :)
We have a PCI network interface, developed by Martin Mares. Donald does
not use that interface, instead choosing to use his own.
We have a kernel resource allocation interface. Donald's code uses it
very poorly, which causes problems throughout the system because it is
impossible for hotplug to allocate resources correctly [when the view of
the system is not complete].
We have a kernel SMP interface, spinlocks, semaphores, and so on.
Donald's drivers do not use this, and as a result often have severe
problems with SMP boxes. I know, I have fixed all of these bugs in his
code.
This is one reason why infrastructure exists -- so that all drivers will
play nicely with each other. Donald chooses to create his own
infrastructure, and as such makes the entire system more unstable
because of this.
> > 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."
>
> He appears almost daily on the various NIC lists.
So what? Show me the code. He updates his drivers very infrequently,
unless you consider August 1999 recent.
> > 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
>
> (pardons to the USB crew to use you :) How much USB development is actually
> talked about on l-k? There's a fairly steep ratio between linux-kernel and
> linux-usb.
>
> There is discussion and it filters quite quickly from l-k to l-t.
If you want to change the kernel core, you discuss it on linux-kernel
not linux-tulip.
> > Um, it is Linus source tree.
>
> And it is Donald's NIC drivers. ...a LOT of them.
If you want to work with the Linux kernel, you work with Linus and the
other kernel developers. No man is an island, ESPECIALLY when you are
talking about the most popular net drivers in the Linux world.
> > 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.
>
> Why do you choose to ignore the linux-tulip list where the work happens?
I don't, I save all the bug reports and reply privately to some of them.
> > We cannot afford to wait many months, with broken network drivers, while
> > Donald does his thing.
>
> The months of broken drivers are because the powers that be chose not to
> allow the current code to be brought into the tree because it had changed too
> much.
No, his code was not merged because it was BROKEN. And he ignored
problems with it sent to him publicly and privately.
> > 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].
>
> Well, I'd be pretty irritated when the kernel version keeps getting hacked
> left and right to fix one thing which breaks another and none of it reported
> directly back to the developer. How much of your changes have you posted to
> him?
EVERY DAMN ONE OF THEM. He gets CC'd on all my patches to Linus, and
sometimes gives helpful feedback. If he doesn't incorporate changes
e-mailed directly to him, that is his (and his users') tough luck.
> > 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.
>
> Well, his driver worked for me, reliably. Double or not. I'd rather have
> the double alloc mem than have a driver that is totally broken.
He has no solution for 2.4.0 stable kernel. Even his attempt at 2.3
drivers are now woefully out of date and won't even compile.
> > 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.
>
> Why is it then that Donald's drivers always seem to work more than the driver
> in the kernel? A bug pops up and is reported on linux-tulip and we get a
> fix. A bug pops up on l-k and two months later we still have the same
> version in the kernel. Repeated gripes about it being broken don't get us
> very far.
If there is a problem in the stable series that is not being addressed,
yell and scream and wave your arms.
If there is a problem in the development series, sure that might take
more time to get fixed. That's the nature of the kernel development
series.
Jeff
-- Jeff Garzik | My to-do list is a function Building 1024 | which approaches infinity. MandrakeSoft, Inc. |- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:25 EST