[36] in linux-net channel archive
Re: A modular history (net modules)
daemon@ATHENA.MIT.EDU (Paul Gortmaker)
Sun Jan 29 01:09:26 1995
From: Paul Gortmaker <paul@rasty.anu.edu.au>
To: linux-kernel@vger.rutgers.edu
Date: Sun, 29 Jan 1995 16:09:59 +1000 (EST)
Cc: linux-net@vger.rutgers.edu
Bjorn wrote:
> My version of the modular history...
[...]
> registering/unregistering net-drivers, but it worked so nice that
> I modularized Don's driver for my 3c509 while I was as it, and then
...actually, the '509 shouldn't *really* be a module because the
probe (the 0x100 ID port probe) will reset *all* other 3c509 cards
in the system. This is something that reserve_region() can't help
with. So if you have one card up and running, and then try
"insmod 3c509.o" you will stomp on the running card. Thanks to
Don for pointing this out. While we are at it, the 509 module is
missing a release_region() call. Which means that you can only
load it once...
On a similar line of reasoning, for those who want to try making
modules out of present ethernet drivers, it is not just a matter
of sticking in init_module() and cleanup_module(). You really
should be able to test multiple card configurations to make sure
that works ok too. And ideally, one should avoid nasty probes that
touch a lot of ports. Safe reads from EEPROMs are nicest. Best to
force the user for an IRQ and an i/o if it is a module. See the
new 21040/DEC de4x5.c driver code for an example of this.
And don't forget to give back your IRQ, i/o region and free your
dev->priv memory. Forgetting the first two will mean that you can't
reload the module a second time, and forgetting the third will
result in a memory leak. The present 3c501 module forgets all three. :-(
But then again you shouldn't use a 3c501 for anything other than
a doorstop or a chew-toy for your dog.
Paul.
