From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: (remove) event not supported.
Date: Sat, 31 Mar 2001 16:52:33 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-98605789632503@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-98597321622555@msgid-missing>
> >It's not a reference count, since it doesn't address the case where
> >another module references it
>
> It is a dynamic reference count. The reference from another module is
> a static reference count. Historical.
I see what you're saying, but that doesn't mean I'd then agree
to call it a "reference" count!
> >Since the counter can be (as
> >you highlighted!) updated at any time, there's nothing to make it
> >be a "reference" count.
> > The networking framework is pretty explicit
> >that it must be used as an "open" count
>
> If networking framework says that then it is wrong.
>
> >(SET_MODULE_OWNER arranges this).
>
> SET_MODULE_OWNER only exports the address of the module structure so
> external code can adjust the use count.
When the interface is opened or closed ... and a few other
cases related to calling into the module. (Related point: I
suspect the USB code should do the same when it probes
drivers, to avoid those same races.)
From the perspective of a normal user, "lsmod" for net
drivers shows use count 0 when no interface exposed
by that driver is "up" (open).
> Normally that is via the open
> routine, but file systems just do one MOD_INC_USE_COUNT in fs/super.c
> so it is a mount count, not an open count. Some netfilter modules want
> to count the number of packets controlled by that module, again not an
> open count.
I'd argue those are all logically equivalent to "open": dynamic
behavior (as you noted) that needs to prevent "rmmod".
One hopes that opening a block device like /dev/sda1 with
a user mode tool, rather than "mount", will prevent "rmmod"...
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2001-03-31 16:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-30 17:21 (remove) event not supported David Brownell
2001-03-31 1:00 ` Brad Hards
2001-03-31 2:03 ` Keith Owens
2001-03-31 2:12 ` Brad Hards
2001-03-31 3:48 ` David Hinds
2001-03-31 8:55 ` Brad Hards
2001-03-31 14:56 ` David Brownell
2001-03-31 15:02 ` David Brownell
2001-03-31 15:49 ` Keith Owens
2001-03-31 16:05 ` David Brownell
2001-03-31 16:18 ` Keith Owens
2001-03-31 16:52 ` David Brownell [this message]
2001-04-01 3:02 ` David Hinds
2001-04-01 3:03 ` David Hinds
2001-04-01 5:26 ` Douglas Gilbert
2001-04-02 2:56 ` Trond Eivind Glomsrød
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=marc-linux-hotplug-98605789632503@msgid-missing \
--to=david-b@pacbell.net \
--cc=linux-hotplug@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.