> > > drivers/net/via-rhine.c:
> > > * (bad patch?) should not be defining ioremap into vremap
> >
> > These don't appear to match any of my versions.
>
> Your version appears to have the same bugs however and a whole pile more.
>
> The actual changes are:
>
> o Cleaning out the optimise check which breaks debugging kernel builds
Without optimization I/O operations are not inlined.
> o Using the new PCI resource structures
> o s/struct device/struct net_device
This has done to all of the PCI drivers. See
http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html
ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/*
> o Removing some of the back compatibility ifdefs to make the code more
> maintainable in 2.3.x
There are very few #ifdefs in those drivers.
Most #ifdefs have been moved kernel compatibility header file.
The few remaining are not easily moved.
Declaring support for multiple kernel versions as unacceptable is absurd.
Driver development should always be done on stable kernels, and then the
stable version forward-ported.
> Both versions of the via rhine driver
> o Don't handle memory resources right with 2.3.x (ie
> check_mem_region and friends)
The check_mem_region() functionality doesn't exist in older kernel version.
The work-around is to use check_region()/register_region() for both memory
and I/O spaces.
The problem also points out that the PCI driver probes are incorrectly
called a bunch of times at boot, and the structure has a foolish flaw that
limits "eth??" naming to only 16 cards.
> o Blindly assume kmalloc won't fail. Sane at boot maybe but not for
> a module load
> o Misdefine ioremap into vremap for Alpha
That bug was caused by you during a bad merge into the kernel. It did not
exist in the original source code.
Donald Becker
Scyld Computing Corporation, and
USRA-CESDIS, becker@cesdis.gsfc.nasa.gov
-
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/