Donald Becker wrote:
> On 9 May 2000, James H. Cloos Jr. wrote:
>
> > Did more testing (this time w/ pre7-8).
> >
> > (I missed this in pre7-6, but at compile time, gcc complains that
> > epic_init and epic_cleanup are defined but not used.)
> ...
> I don't mean to harp on this,
hehe
> but doesn't anyone even test changes before
> putting them in the kernel? There have been many driver changes that had no
> chance of working. Just a few minutes ago I got a message about the
> starfire driver crashing the kernel during the probe routine. This wasn't an
> operational problem which might only show up with some hardware and specific
> configurations, it showed that the driver has never even been tried.
For epic100 and starfire updates this is true, as I don't have the
hardware. For those two drivers I was relying on valuable feedback from
people like James, to signal that there are problems with the code.
That's what the 2.3.x period is for.. hammering out the rough spots
before 2.4.0 is released. For these type of updates, the problems are
invariably small and incredibly obvious, not major logic flaws in the
entire system.
Originally most of these driver merges started out as a simple merge of
2.2.x net driver code, which is superficially the best thing to do from
a stability standpoint. However, it seems silly to ignore some
important bug fixes and new PCI ids found in your newer drivers. Many
of the 2.2.x net drivers are quite old. Therefore, the procedure now
involves obtaining your latest stable driver, integrating bug fixes from
2.2.x and changes from 2.3.x, and putting the result into 2.3.99-preXX.
I test if possible, and look over the changes quite a bit, but it is
inevitable that some errors will slip through. I think a few typos are
a small price to pay for much improved network drivers in the 2.4.0
kernel.
Why not just use your driver code directly?
Two major problems. First, the easy one, your code just doesn't build
and work with recent kernels. Second, and more importantly, you
recreate kernel infrastructure. You are duplicating logic and behavior
found in other parts of the kernel, for just a few net drivers. Doing
so is moving in the opposite direction of existing kernel convention.
Code duplication due to your PCI framework is not the only problem. By
going off on your own, and building your own independent infrastructure,
your PCI framework does not track important changes and fixes in Power
Management, PCI initialization and wake up, resource management, and
other issues. Due to your framework there is forever a gap between the
kernel drivers and "your" drivers, a gap into which bugs can and do
slip. I know, I have fixed many of those bugs time and time again.
As the author of these drivers it is understandable you might disagree
with some or even all of my changes. The solution is simple: submit
patches to Linus like everyone else. Work with kernel infrastructure
and kernel developers. No man is an island. :)
Jeff
-- Jeff Garzik | ILOVEYOU, Linux. Building 1024 | 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 : Mon May 15 2000 - 21:00:18 EST