From: Rusty Russell <rusty@rustcorp.com.au>
To: Paul Gortmaker <paul.gortmaker@windriver.com>,
linux-kernel@vger.kernel.org
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Subject: Re: [PATCH] kernel: make module.c itself more explicitly non-modular
Date: Wed, 26 Aug 2015 13:36:55 +0930 [thread overview]
Message-ID: <87mvxeitgg.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1440555155-11273-1-git-send-email-paul.gortmaker@windriver.com>
Paul Gortmaker <paul.gortmaker@windriver.com> writes:
> The Kconfig currently controlling compilation of this code is:
>
> menuconfig MODULES
> bool "Enable loadable module support"
>
> ...meaning that it currently is not being built as a module by anyone.
> No surprise here, since modular support being a module would be an
> interesting chicken before the egg problem.
>
> Lets remove the use of module_init in this code so that when reading
> the file, there is less doubt that it is builtin-only.
>
> Since module_init translates to device_initcall in the non-modular
> case, the init ordering remains unchanged with this commit. However
> one could argue that fs_initcall makes more sense for proc stuff,
> and we can change the initcall order later and watch for fallout
> if so desired.
This patch is just weird; is this part of something larger you are
trying to do?
I would argue that module_init() should be the default; it implies
no dependencies on the initialization, and it's a common pattern.
Cheers,
Rusty.
> We can't of course delete the module.h include in this case since it
> is used all through the rest of the file.
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
>
> [I was undecided as to whether we should do this in one step
> or two, i.e. instead just make the change to fs_initcall here
> and now, and so went with the more cautious/granular approach.]
>
> kernel/module.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 8f051a106676..7750bdcb12fc 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3947,7 +3947,7 @@ static int __init proc_modules_init(void)
> proc_create("modules", 0, NULL, &proc_modules_operations);
> return 0;
> }
> -module_init(proc_modules_init);
> +device_initcall(proc_modules_init);
> #endif
>
> /* Given an address, look for it in the module exception tables. */
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2015-08-26 4:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-26 2:12 [PATCH] kernel: make module.c itself more explicitly non-modular Paul Gortmaker
2015-08-26 4:06 ` Rusty Russell [this message]
2015-08-26 13:41 ` Paul Gortmaker
2015-08-27 4:13 ` Rusty Russell
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=87mvxeitgg.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
/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.