From: "Kevin O'Connor" <kevin@koconnor.net>
To: Werner Almesberger <wa@almesberger.net>
Cc: Roman Zippel <zippel@linux-m68k.org>,
Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] Is an alternative module interface needed/possible?
Date: Sun, 23 Feb 2003 18:34:33 -0500 [thread overview]
Message-ID: <20030223183433.A16972@arizona.localdomain> (raw)
In-Reply-To: <20030218142257.A10210@almesberger.net>; from wa@almesberger.net on Tue, Feb 18, 2003 at 02:22:57PM -0300
On Tue, Feb 18, 2003 at 02:22:57PM -0300, Werner Almesberger wrote:
> Next round: possible remedies and their side-effects. As
> usual, if you disagree with something, please holler.
>
> If yes, let's look at possible (and not overly insane) solutions,
> using remove_proc_entry as a case study:
Hi Werner,
Thanks for putting together this list; I've been following this thread for
a while and it seems that the discussion always deteriorates into
semantics. Anyway, I think there is an eighth possible solution to the
list you proposed.
Just to be specific, the requirements for the proc entry stuff are:
a) a mechanism needs to be defined to indicate that the entry is no longer
needed (something that starts the delete process -- ie, remove_proc_entry),
b) the code must conform to a system that ensures de->data will not be used
after the "release" code is executed, and
c) the "release" code must be eventually executed.
Assuming these requirements are really requirements (your options 1 and 4
don't seem to meet these) then an "eighth" solution is:
8) Have the unregister code (remove_proc_entry) set an external flag (eg,
de->data_is_there), and update all users of de->data to check the flag
before following the pointer.
Option 8 may not qualify as "sane", but I think it is important to add it
because it is what the module code is currently using. Thus, one need not
look at the module stuff as a "special case", but as a general (if
complicated) resource management solution.
Finally, one could probably apply any of the "options" for any dynamically
allocated memory. It is interesting that Linus seems to prefer option 2/7
(from the recent kobject work and CodingStyle).
If I've missed something, please let me know.
-Kevin
> 1) still don't kfree, and leave it to the user to somehow
> minimize the damage. (Good luck :-)
>
> 2) add a callback that is invoked when the proc entry gets
> deleted. (This callback may be called before remove_proc_entry
> completes.) Problem: unload/return race for modules.
>
> 3) change remove_proc_entry or add remove_proc_entry_wait that
> works like remove_proc_entry, but blocks until the entry is
> deleted. Problem: may sleep "forever".
>
> 4) make remove_proc_entry return an indication of whether the
> entry was successfully removed or not. Problem: if it
> wasn't, what can we do then ?
>
> 5) like above, but don't remove the entry if we can't do it
> immediately. Problem: there's no notification for when we
> should try again, so we'd have to poll.
>
> 6) export the lookup mechanism, and let the caller poll for
> removal. Problem: races with creation of a new entry with
> the same name.
>
> 7) transfer ownership of de->data to procfs, and set some
> (possibly configurable) destruction policy (e.g. always
> kfree, or such). Similar to 2), but less flexible.
--
------------------------------------------------------------------------
| Kevin O'Connor "BTW, IMHO we need a FAQ for |
| kevin@koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" |
------------------------------------------------------------------------
next prev parent reply other threads:[~2003-02-23 23:24 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 ` [RFC] Is an alternative module interface needed/possible? Roman Zippel
2003-02-18 1:18 ` 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 [this message]
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=20030223183433.A16972@arizona.localdomain \
--to=kevin@koconnor.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=wa@almesberger.net \
--cc=zippel@linux-m68k.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).