From: Rusty Russell <rusty@rustcorp.com.au>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] new module interface
Date: Fri, 26 Jul 2002 13:43:39 +1000 [thread overview]
Message-ID: <20020726034921.368CE4575@lists.samba.org> (raw)
In-Reply-To: Your message of "Thu, 25 Jul 2002 11:56:06 +0200." <Pine.LNX.4.44.0207251121310.28515-100000@serv>
In message <Pine.LNX.4.44.0207251121310.28515-100000@serv> you write:
> Hi,
>
> On Thu, 25 Jul 2002, Rusty Russell wrote:
>
> > Firstly, I give up: what kernel is this patch against? It's
> > hard to read a patch this big which doesn't apply to any kernel I can find
8(
>
> 2.4.18. Maybe pine garbled the patch... Here is a copy of the patch:
> http://www.xs4all.nl/~zippel/mod.diff
Much better: thanks!
> > Interesting approach. Splitting init and start and stop and exit is
> > normal, but encapsulating the usecount is different. I made start
> > and exit return void, though.
>
> I introduced usecount() to gain more flexibility, currently one is forced
> to pass the module pointer everywhere.
Well, you substituted the module pointer for an atomic counter. Bit
of a wash, really.
> Allowing exit to fail simplifies the interface. Normal code doesn't has
> to bother about the current state of the module, instead exit() is now the
> synchronization point. This also means the unload_lock via
> try_inc_mod_count is not needed anymore.
Except that rmmod fails rather frequently on busy modules. Which
might be ok.
> > I chose the more standard "INIT(init, start)" & "EXIT(stop, exit)" which
> > makes it easier to drop the exit part if it's built-in.
>
> I was thinking about it, but couldn't we just put these function in a
> seperate section and discard them during init (maybe depending on some
> hotplug switch)?
No, if you drop them newer binutils notices the link problem, hence
the __devexit_p(x) macro.
> > My favorite part is including the builtin-modules. I assume this means
> > that "request_module("foo")" returns success if CONFIG_DRIVER_FOO=y now?
>
> Not yet. The problem is the module name, e.g. ext2 is called
> fs_ext2_super, it will need some kbuild changes to get the right module
> name.
I need that too: the mythical "KBUILD_MODNAME". Both Keith and Kai
promised it to me...
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2002-07-26 3:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-24 20:02 [PATCH][RFC] new module interface Roman Zippel
2002-07-25 8:08 ` Rusty Russell
2002-07-25 9:56 ` Roman Zippel
2002-07-26 3:43 ` Rusty Russell [this message]
2002-07-26 4:22 ` Keith Owens
2002-07-26 10:12 ` Roman Zippel
2002-07-27 6:49 ` Rusty Russell
2002-07-28 11:57 ` Roman Zippel
2002-07-26 18:15 ` Kai Germaschewski
2002-07-27 7:00 ` Rusty Russell
2002-07-27 17:11 ` Kai Germaschewski
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=20020726034921.368CE4575@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=linux-kernel@vger.kernel.org \
--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