use code in module_exit?

[Pavel Roskin]

On Mon, 18 Aug 2003, Dominik Brodowski wrote:

> which means that if DEV_STALE_CONFIG is set while doing
> pcnet_driver->detach(), dev_link_t *link isn't removed from the
> dev_list. This is only done if either pcnet_driver->attach() calls
> flush_stale_links, or (hopefully) in the second run being called by
> exit_pcnet_cs().

This is actually a problem.  There is no way to guarantee that the device
with be actually detach()ed.  Let me describe a real problem that happened
to me.

All drivers were compiled into the kernel because it was an embedded
system.  There were two different cards supported by two different PCMCIA
drivers.  The scripts assumed that whatever card is inserted, if would be
eth2 (since eth0 and eth1 were on the board).  However, sometimes the new
card would become eth3, and eth2 would stay as a zombie.

The reason was that the script to bring the interface down would run too
slowly compared to the delay in the driver (no wonder, it was a
full-featured bash on a slow ARM processor with CompactFlash as storage).
Thus, the device would not be brought down in time for the second try.

Since drivers were part of the kernel, the detach() would not be called on
the module unload.  If a different card was inserted after that, the
attach() from the new driver would not flush devices from the old driver
(because is only goes through the list of the devices supported by the
same driver).  So, instead of eth2, eth3 was used, which caused a lot of
inconvenience in the scripts.

That what the reason why I eliminated the timer and simplified the unload
process in orinoco_cs.  Perhaps the same thing needs to be done with other
drivers.

However, orinoco_cs used its own locking, and I'm not sure that the
simplified code would be safe without it.

As for pcnet_cs, it has always been an exception, and I remember writing
an e-mail to David Hinds asking to implement the driver unregistration in
a consistent way.  It should be OK to change pcnet_cs just like other
drivers.  The whole multi-stage process must be a workaround for some
problems with the network layer, not the hardware, and I believe those
problems have been solved since then.

-- 
Regards,
Pavel Roskin