Re: PATCH 2.3.23 pre 2 compile fixes

Alan Cox (alan@lxorguk.ukuu.org.uk)
Tue, 19 Oct 1999 20:24:28 +0100 (BST)


> > o Cleaning out the optimise check which breaks debugging kernel builds
> Without optimization I/O operations are not inlined.

The debugging patches I and afaik others use deal with that.

> > 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/*

These use the new pci scan code when Linus picked Jeff Garzik's stuff instead
so that needs sorting but yes I know about this. I merged them, ran into the
resource problems and didnt think they warranted feeding on in their state
at the time (ie the very first bash at MMIO support)

> There are very few #ifdefs in those drivers.
> Most #ifdefs have been moved kernel compatibility header file.
> The few remaining are not easily moved.

Nod. I liked that part of the change a lot

> > 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.

This is potentially wrong for non x86 and wrong for 2.3.x though even if it
is a sane hack for 2.2.x.

> 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.

The eth?? thing is a bug. The multiple probe is a symptom of a bug in
the driver. Suppose two drivers are on the machine for the same PCI card
(eg if someone has decided to use 3coms card driver for the 3c90x and
loads yours to get his 3c595 handled too).

Also at least in the revision I had it was using the virtual not physical
address. The physical address was only around in the pci-scan code.

> > 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.

The ioremap one looks like my fault but the others..

#if (LINUX_VERSION_CODE >= 0x20100)
char kernel_version[] = UTS_RELEASE;

Should be static or you get a symbol clash with 2 of the drivers compiled
in.

np = (void *)(((long)kmalloc(sizeof(*np), GFP_KERNEL) + 31) & ~31);
memset(np, 0, sizeof(*np));

The malloc isnt NULL checked, and the block isnt freed on unload.

So yes you are right about the vmalloc being my error. sorry. The others are
long standing things I've reported before.

Also notionally init_etherdev() could return NULL and should be checked. THat
is something that needs propogating on since its more of a rule change than
a bug.

Alan

-
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/