Donald Becker wrote:
On Thu, 12 Dec 2002, Jeff Garzik wrote:
Donald Becker wrote:
[[ I don't know why I bother. The people that now control what goes into
the kernel would rather put in random patches from other people than
accept a correct fix from me. ]]
I'm very interested in applying fixes from you! I am publicly begging
you to do so, and even CC'ing lkml on my request.
This is very disingenuous statement.
Oh come on, it's far less disingenuous than what you said:
[[ I don't know why I bother. The people that now control what
goes into the kernel would rather put in random patches from
other people than accept a correct fix from me. ]]
I'm sure you'll continue making snide comments on every mailing list you
maintain, but the fact remains:
I would much rather accept a fix from you.
That hasn't changed in the past year. or two. or any amount of time.
Your input is very valuable, and I typically save quite a few of your
emails.
The drivers in the kernel are now heavily modified and have significantly
diverged from my version. Sure, you are fine with having someone else
do the difficult and unrewarding debugging and maintainence work, while
you work on just the latest cool hardware, change the interfaces and are
concerned only with the current kernel version.
While I disagree with this assessment, I think we can safely draw the
conclusion that the problem is _not_ people ignoring your patches, or
preferring other patches over yours.
I've been actively developing Linux drivers for over a decade, and run
about two dozen mailing lists for specific drivers. I write diagnostic
routines for every released driver. I thoroughly test and frequently
update the driver set I maintain. And since about 2000, my patches were
ignored while the first notice I've have gotten to changes in my drivers
is the bug reports. And the response: "submit a patch to fix those
newly introduced bugs". I've even had patches ignore in favor of people
that wrote "I don't have the NIC, but here is a change".
I don't recall _ever_ getting a patch from you or seeing one posted on
lkml or netdev. How can you be ignored if you're not sending patches?
A good example is the tulip driver. You repeatedly restructured my
driver in the kernel, splitting into different files. It was still 90+%
my code, but the changes made it impossible to track the modification
history. The kernel driver was long-broken with 21143-SYM cards, but no
one took the responsibility for fixing it.
s/was/is/
I take responsibility for fixing it, I just haven't fixed it yet :)
It's easy to make the first few patches, when you don't have to deal
with reversion testing, many different models, and have an unlimited
sandbox where it doesn't matter if a specific release works or not. But
it takes a huge of work to keep a stable, tracable driver development
process that works with many different kernel versions and hardware
environments.
We're slowly getting there, in terms of regression and stress testing.
Since you don't send patches anymore for a long time, I was really the
only one [stupid enough?] to stand up and even bother to help collecting
and reviewing net driver changes.
I would love to integrate your drivers directly, but they don't come
anywhere close to using current kernel APIs. The biggie of biggies is
not using the pci_driver API. So, given that we cannot directly merge
your drivers, and you don't send patches to kernel developers, what is
the next best alternative? (a) let kernel net drivers bitrot, or (b)
maintain them as best we can without Don Becker patches? I say that "b"
is far better than "a" for Linux users.
Jeff
|