[3652] in linux-net channel archive
Re: new lance patch
daemon@ATHENA.MIT.EDU (Paul Gortmaker)
Fri Jul 12 19:31:58 1996
From: Paul Gortmaker <gpg109@rsphy1.anu.edu.au>
To: MC3641@mclink.it (Tekno Soft Snc)
Date: Fri, 12 Jul 1996 11:55:41 +1000 (EST)
Cc: linux-net@vger.rutgers.edu, tsbogend@bigbug.franken.de,
becker@cesdis1.gsfc.nasa.gov
In-Reply-To: <9607101332.aa18717@ax433.mclink.it> from "Tekno Soft Snc" at Jul 10, 96 01:32:57 pm
>
> Hi all,
>
> this patch reorganize the lance driver when is used with the lance32
> option enabled. It free about 6/8Kb.
If there is *really* a need for a lance + lance32 driver, then rather
than sprinkle #ifdef sets all through the code, it would be much
cleaner to move the common code into a separate file, such as AM7990.c
akin to how the 8390 common code is in one separate file. Then you
would have lance16.c and lance32.c using those core functions, with PCI
probing specifics only in lance32.c, ISA DMA only in lance16.c etc. etc.
This would also open up those core functions for use in other drivers
such as sunlance.c and ni65.c thus allowing more code-sharing.
However, I am not clear on why lance32 exists at all. Perhaps I am
missing some crucial point that Thomas B. can clarify for me. When I
do a "diff -u lance.c lance32.c" I don't see a significant difference
to justify the existence of two separate drivers. It appears that
lance32.c is just a clone of lance.c with the chip_table containing
the ISA variants tossed in the bin, plus some other minor changes,
such as a couple outw() to enable 32 bit mode. Was/is there some
fundamental conflict that couldn't be handled like all the other model
differences, (i.e. via the chip_table) and thus cloning the driver as
lance32.c was the only option?
Paul.
