Jeff Garzik wrote:
> Correct. Kernel infrastructure is developed, and Donald ignores that
> infrastructure.
Hmmmm. No.
> 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.
> 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.
> Um, it is Linus source tree.
And it is Donald's NIC drivers. ...a LOT of them.
> 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?
> 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. This wasn't any fault of Donald. Anyone is free to update the incore
version to match the developer's version. It happens all the time.
> 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?
> 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.
Or you end up with tulip drivers that work for you but break on three
different things for me.
> 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.
> 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.
-d
--
\\\\\|||||| &%&%&%& 99 little bugs in the code, 99 bugs in the code,
@|~|' |o> @|& fix one bug, compile it again...
| \\__/ | /, |& 101 little bugs in the code....
\ / -' ,
E-- |--HUGS---
-
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:20 EST