> You can have the largest test lab, you can have thousands or millions
> of cards to verify things on, but it will never be any match for the
> cast of wacky configurations that users have who actively test and
> beat on the official release and pre-patch kernels done by Alan and
> Linus have.
I'm sure many people are in the same boat I am. We argue and fight to allow
one of Donald's drivers to be put in the kernel and it doesn't happen. So we
keep on doing what we do, we get drivers from CESDIS and plop them into our
source. Our feedback then goes to linux-tulip and Donald because it's fairly
senseless reporting on it here. *That* driver isn't supported here, only the
driver that AC updates.
The linux-* lists on ethernet cards are quite lively and provide a
considerable amount of feedback.
The NIC drivers are so out of date in the kernel that it -will- take a large
patch just so that patch keeps things working. Heck, my idea of a patch at
this point is "cp". If you only allow tiny little patches, then you're
likely to break more systems than you are going to fix until you get to a
certain point.
As much water has passed under the bridge for these drivers, I honestly think
it would be easier for whomever to review a new file versus a patch set.
You have to appreciate Donald's position. Drivers for network cards, we can
use the tulip for example, are a horror. It's not "adaptec xxxx" where
parameters rarely change. With the tulip cards, everybody's mother's uncle's
brother's sister has a different eeprom format, some mii implementation from
mars, and a hardwired onboard fix for something that breaks another thing.
By far and large, Donald's NIC drivers far exceed the kernel's drivers when
it comes down to the simple fact of does it work or doesn't it.
The future is fast approaching and the total level of work required to review
patch code is simply going to be more than one single person can do. We (you
most perhaps) need to find a solution that works. Trusting a delegate to
make the right decisions on code is going to be necessary. The further we
go, the more broad we grow. If we don't cope with that breadth of growth,
then quality overall is going to fall as the patch integrator takes on more
and more workload.
Donald's doing a good job. One solution for thought is peer review by
trusted top guys. If Dave M and Donald get together, do tea, and come out
blessing a new "tulip.c" file, then put the new file in place. Don't
trouble Linus to wade through 179 little patches that must nearly all be
applied to come out with a still functional driver.
Delegate some trust relationships and spread the load out. It's a lot easier
for Linus to take the recommendation of this code review by multiple people
and say "go for it" than it is for two people to banter patches back and
forth until it's all done.
Give it some thought please.
-d
-- This is Linux Country. On a quiet night, you can hear Windows NT reboot! Do you remember how to -think- ? Do you remember how to experiment? Linux __ is an operating system that brings back the fun and adventure in computing. \/ for linux-kernel: please read linux/Documentation/* before posting problems
- 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/