From: Rusty Russell <rusty@rustcorp.com.au>
To: Christoph Hellwig <hch@ns.caldera.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Updated parameter and modules rewrite (2.4.14)
Date: Fri, 23 Nov 2001 12:28:17 +1100 [thread overview]
Message-ID: <E16758b-0001xO-00@wagner> (raw)
In-Reply-To: Your message of "Thu, 22 Nov 2001 11:08:28 BST." <200111221008.fAMA8Sa04042@ns.caldera.de>
In message <200111221008.fAMA8Sa04042@ns.caldera.de> you write:
> In article <E166p1R-0004ll-00@wagner> you wrote:
> > http://ftp.kernel.org/pub/linux/kernel/people/rusty
> >
> > Unified boot/module parameter and module loader rewrite
> > updated to 2.4.14. I'm off to Linux Kongress, so I'll be difficult to
> > contact for 10 days or so.
>
> I absolutly oppose to the cosmetic naming changes.
Hi Christoph!
Um, me too. I should have reposted my previous explanation, sorry!
> Please let module be be initialized by module_init() and exited by
> module_exit(). We had a hard enough time to get it everywhere, not
> to mention the name makes a lot of sense.
Unfortunately, removal needs to be done in two stages, to sanely make
things like IPv6 modular (a deactivate, and a kill stage). It turns
out that this applies to loading as well, in case the loading fails
part way through (there's also a number of modules at the moment which
initialize in the wrong order, which can lead to an oops).
> Also MODULE_PARAM should just stay, combined with Keith's proposal
> to use it at boottime aswell (as KBUILD_OBJECT.<paramname>).
Firstly, Keith and I agree on KBUILD_OBJECT[/.]paramname, BTW. I'm
not sure it was his proposal originally, though: it's a pretty simple
and old idea.
The previous module param stuff was prone to user bugs (no type
checking), was not extensible, and required duplicated code for boot
time. It also did not have the option of appearing in /proc.
It is possible to write macros mapping the NEW macros to the OLD, but
not vice versa, otherwise I wouldn't change at all.
Hope that clarifies,
Rusty.
--
Premature optmztion is rt of all evl. --DK
next prev parent reply other threads:[~2001-11-23 1:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-22 8:15 [PATCH] Updated parameter and modules rewrite (2.4.14) Rusty Russell
2001-11-22 10:08 ` Christoph Hellwig
2001-11-23 1:28 ` Rusty Russell [this message]
2001-11-23 14:15 ` Martin Dalecki
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=E16758b-0001xO-00@wagner \
--to=rusty@rustcorp.com.au \
--cc=hch@ns.caldera.de \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox