[dhinds@sonic.net: Re: use code in module_exit?]

[Christoph Hellwig]

This might be of general interest.

----- Forwarded message from David Hinds <dhinds at sonic.net> -----

Date: Fri, 22 Aug 2003 08:55:20 -0700
From: David Hinds <dhinds at sonic.net>
Subject: Re: use code in module_exit?
To: hch at infradead.org
Cc: proski at gnu.org

Christoph,

If you have questions like this about intent of something in PCMCIA
code I wrote, you can just ask me, and I'll tell you and avoid any
pointless speculation.

The cleanup code you're talking about, was implemented back when
release code was executed in interrupt or timer context.  There were
situations where the detach had to be postponed (device running), and
when the release code was finally executed in timer context, it could
not then do the delayed detach, because the detach code needed to be
able to sleep.

Now, with release() always called in thread context, this is indeed no
longer necessary.  You can delete the flush_stale_links() stuff, as
long as you add to the end of each release function:

    if (link->state & DEV_STALE_LINK)
        detach(link);

This is in fact how all the *_cs drivers worked for pre-2.2 kernels.

Regarding Pavel's statement:

> Speaking of the network devices (if more familiar with them) it
> means that the network device should be unregistered even if it's
> not brought down by the script.

I think this is quite wrong, and maybe impossible.  I don't think
there is a mechanism for a network device driver to close an open
interface; it has to be done by the user.  I think the interface name
should stick around until the user closes it, and that this is
consistent with the "principle of least surprise".  Otherwise you
could get situations where an interface disappears and another one
appears with the same name, before user space has time to respond to
the first device going away.

Pavel's scripts that assumed that a hot plugged device would always
pop up with the same interface name were broken.  There are defined
mechanisms for obtaining the interface name that always work.

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

I don't think this is correct; orinoco_cs was broken, and pcnet_cs
uses (now anyway, I don't remember if it was always true) the same
mechanism as the other *_cs network drivers.

-- Dave

----- End forwarded message -----