From: Roman Zippel <zippel@linux-m68k.org>
To: Werner Almesberger <wa@almesberger.net>
Cc: Rusty Russell <rusty@rustcorp.com.au>, <kuznet@ms2.inr.ac.ru>,
<davem@redhat.com>, <kronos@kronoz.cjb.net>,
<linux-kernel@vger.kernel.org>
Subject: [RFC] Is an alternative module interface needed/possible?
Date: Tue, 18 Feb 2003 00:09:04 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.44.0302172019220.1336-100000@serv> (raw)
In-Reply-To: <20030217140423.N2092@almesberger.net>
Hi,
(Subject changed to hopefully get a bit more attention.)
On Mon, 17 Feb 2003, Werner Almesberger wrote:
> > If we exclude the possibly-wait-forever-option, do you see the problem
> > for dynamic objects which also contain references to static data/
> > functions?
>
> You mean that two locking mechanisms are used, where one of them
> shouldn't be doing all that much ? Well, yes.
>
> Now, is this a problem, or just a symptom ? I'd say it's a symptom:
> we already have a perfectly good locking/synchronization method,
> and that's through the register/unregister interface, so the
> module-specific part is unnecessary.
If it was perfectly good, we hadn't a problem. :)
> That much about the theory. Of course, in real life, we have to
> face a few more problems:
>
> - if callbacks can happen after apparently successful "unregister",
> we die
> - if accesses to other static data owned by a module can happen
> after apparently successful "unregister", we may die
> - if a module doesn't "unregister" at all, we die too
>
> But all these problems equally affect code that does other things
> that can break a callback/access, e.g. if we destroy *de->data
> immediately after remove_proc_entry returns.
>
> So this is not a module-specific problem.
You're skipping ahead. You haven't solved the problem yet, but you're
already jumping to conclusions. :-)
Remember, that we want to savely remove a proc entry and as added bonus,
we only want a single reference count. Let's look first at the possible
solutions:
module count: by design this only works for entries, which are removed
during module exit, but not for dynamic entries.
failure: if the object is still busy, we just return -EBUSY. This is
simple, but this doesn't work for modules, since during module exit you
can't fail anymore.
callbacks: the callback function itself had to be protected somehow, so
just to unregister a proc entry, you have to register a callback. To
unregister that callback, it would be silly to use another callback and
failure doesn't work with modules, so that only leaves the module count.
The last solution sounds complicated, but exactly this is done for
filesystems and we didn't really get rid of the second reference count, we
just moved it somewhere else, where it hurts least.
Without interface changes this is also the only generic option to export
dynamic data - the drivers have to get a filesystem like interface (or
just become filesystem themselves).
The very basic reason which prevents another solution is that static data
(which includes functions) is controlled by the generic module code and
dynamic data is controlled by the driver itself. It's obvious that we
can't give the module code control over dynamic data, on the other hand
would it be possible to give the driver control over the static data? This
way it suddenly it becomes a module-specific problem - how can we give
drivers more control over its data?
bye, Roman
next prev parent reply other threads:[~2003-02-17 22:59 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-02 22:50 [RFC] Migrating net/sched to new module interface Kronos
2003-01-03 5:10 ` Rusty Russell
2003-01-03 8:37 ` David S. Miller
2003-01-04 6:09 ` Rusty Russell
2003-01-04 16:21 ` Kronos
2003-01-13 22:32 ` kuznet
2003-01-13 23:23 ` Max Krasnyansky
2003-01-14 17:49 ` Kronos
2003-01-15 0:21 ` Roman Zippel
2003-01-15 1:19 ` kuznet
2003-01-15 7:31 ` Werner Almesberger
2003-01-15 8:16 ` Rusty Russell
2003-01-15 9:33 ` Werner Almesberger
2003-01-16 1:12 ` Rusty Russell
2003-01-16 2:42 ` Werner Almesberger
2003-01-16 3:31 ` Rusty Russell
2003-01-16 4:20 ` Werner Almesberger
2003-01-16 4:25 ` David S. Miller
2003-01-16 4:49 ` Werner Almesberger
2003-01-16 16:05 ` Roman Zippel
2003-01-16 18:15 ` Roman Zippel
2003-01-16 18:58 ` Werner Almesberger
2003-01-16 23:53 ` Roman Zippel
2003-01-17 1:04 ` Greg KH
2003-01-17 2:27 ` Rusty Russell
2003-01-17 21:40 ` Roman Zippel
2003-02-13 23:16 ` Werner Almesberger
2003-02-14 1:57 ` Rusty Russell
2003-02-14 3:44 ` Werner Almesberger
2003-02-14 11:16 ` Roman Zippel
2003-02-14 12:04 ` Rusty Russell
2003-02-14 12:49 ` Roman Zippel
2003-02-17 1:59 ` Rusty Russell
2003-02-17 10:53 ` Roman Zippel
2003-02-17 23:31 ` Rusty Russell
2003-02-18 12:26 ` Roman Zippel
2003-02-14 13:21 ` Roman Zippel
2003-02-14 13:53 ` Werner Almesberger
2003-02-14 14:24 ` Roman Zippel
2003-02-14 18:30 ` Werner Almesberger
2003-02-14 20:09 ` Roman Zippel
2003-02-15 0:12 ` Werner Almesberger
2003-02-15 0:51 ` Roman Zippel
2003-02-15 2:28 ` Werner Almesberger
2003-02-15 23:20 ` Roman Zippel
2003-02-17 17:04 ` Werner Almesberger
2003-02-17 23:09 ` Roman Zippel [this message]
2003-02-18 1:18 ` [RFC] Is an alternative module interface needed/possible? Werner Almesberger
2003-02-18 4:54 ` Rusty Russell
2003-02-18 7:20 ` Werner Almesberger
2003-02-18 12:06 ` Roman Zippel
2003-02-18 14:12 ` Werner Almesberger
2003-02-18 12:45 ` Thomas Molina
2003-02-18 17:22 ` Werner Almesberger
2003-02-19 3:30 ` Rusty Russell
2003-02-19 4:11 ` Werner Almesberger
2003-02-19 23:38 ` Rusty Russell
2003-02-20 9:46 ` Roman Zippel
2003-02-20 0:40 ` Roman Zippel
2003-02-20 2:17 ` Werner Almesberger
2003-02-23 16:02 ` Roman Zippel
2003-02-26 23:26 ` Werner Almesberger
2003-02-27 12:34 ` Roman Zippel
2003-02-27 13:20 ` Werner Almesberger
2003-02-27 14:33 ` Roman Zippel
2003-02-23 23:34 ` Kevin O'Connor
2003-02-24 12:14 ` Roman Zippel
2003-02-18 12:35 ` Roman Zippel
2003-02-18 14:14 ` Werner Almesberger
2003-02-19 1:48 ` Roman Zippel
2003-02-19 2:27 ` Werner Almesberger
2003-01-16 13:44 ` [RFC] Migrating net/sched to new module interface Roman Zippel
2003-01-15 17:04 ` Roman Zippel
2003-02-20 12:09 [RFC] Is an alternative module interface needed/possible? Adam J. Richter
2003-02-20 12:46 ` Roman Zippel
2003-02-20 13:51 Adam J. Richter
2003-02-20 14:06 ` Werner Almesberger
2003-02-20 15:38 ` Roman Zippel
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=Pine.LNX.4.44.0302172019220.1336-100000@serv \
--to=zippel@linux-m68k.org \
--cc=davem@redhat.com \
--cc=kronos@kronoz.cjb.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=wa@almesberger.net \
/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).