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 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.