netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: "David S. Miller" <davem@redhat.com>
Cc: jgarzik@pobox.com, shemminger@osdl.org, netdev@oss.sgi.com,
	greg@kroah.com
Subject: Re: [Fwd: pcmcia ether drivers can't be unloaded]
Date: Sat, 7 Aug 2004 12:09:43 +0100	[thread overview]
Message-ID: <20040807120943.A2805@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20040728085419.773c4d94.davem@redhat.com>; from davem@redhat.com on Wed, Jul 28, 2004 at 08:54:19AM -0700

On Wed, Jul 28, 2004 at 08:54:19AM -0700, David S. Miller wrote:
> On Wed, 28 Jul 2004 16:50:24 +0100
> Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Jul 27, 2004 at 05:19:29PM -0700, David S. Miller wrote:
> > > I totally disagree.  This is a bogus argument for two reasons:
> > 
> > You may disagree, that is your option.  However, facts are facts -
> > this is how the PCMCIA layer currently works, and short of rewriting
> > the whole damned thing it isn't going to change.  Sorry.
> 
> Stephen offered a solution, moving this stray refcount into a toplevel
> pcmcia bus type object.  We are not constrained by how the PCMCIA layer
> currently works, just as we were not constrained a year ago by how the
> generic network device handling worked when it was totally broken in
> this area.  We just fixed it instead of whining.

Right, I now have sufficient time to investigate and provide a proper
response.

The reason PCMCIA modules _as a whole_ (ie, not limited to just PCMCIA
network drivers) are not unloadable while in use is that:

(1) the PCMCIA subsystem keeps references to structures inside the
    PCMCIA card driver module while the driver is bound (by the
    userspace daemon) to the PCMCIA card.

(2) the userspace daemon, cardmgr, keeps track of which PCMCIA
    card driver modules are loaded, and loads and unloads them
    as necessary.

Short of rearchitecting the way the PCMCIA userspace daemon works, I
don't see an easy fix for this.  Therefore, as I've already said, the
current behaviour stands for 2.6.  PCMCIA is _far_ too fragile to
risk doing a rewrite to get the locking and structure refcounting
rules correct overnight.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

      parent reply	other threads:[~2004-08-07 11:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <41068BEF.7010200@pobox.com>
2004-07-27 22:36 ` [Fwd: pcmcia ether drivers can't be unloaded] Russell King
2004-07-28  0:19   ` David S. Miller
2004-07-28 15:50     ` Russell King
2004-07-28 15:54       ` David S. Miller
2004-08-02 19:02         ` Russell King
2004-08-07 11:09         ` Russell King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040807120943.A2805@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=davem@redhat.com \
    --cc=greg@kroah.com \
    --cc=jgarzik@pobox.com \
    --cc=netdev@oss.sgi.com \
    --cc=shemminger@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).