From: Rusty Russell <rusty@rustcorp.com.au>
To: Paul Gortmaker <paul.gortmaker@windriver.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel: make module.c itself more explicitly non-modular
Date: Thu, 27 Aug 2015 13:43:48 +0930 [thread overview]
Message-ID: <87bndtid1f.fsf@rustcorp.com.au> (raw)
In-Reply-To: <55DDC212.4060309@windriver.com>
Paul Gortmaker <paul.gortmaker@windriver.com> writes:
> On 2015-08-26 12:06 AM, Rusty Russell wrote:
>> 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?
>
> Yes, it is part of a larger cleanup; for subsystems with more than
> one patch I created a 0/N explanatory note; such as:
>
> https://lkml.kernel.org/r/1440459295-21814-1-git-send-email-paul.gortmaker@windriver.com
> https://lkml.kernel.org/r/1437530538-5078-1-git-send-email-paul.gortmaker@windriver.com
>
> and others. Apologies for the lack of context on this single patch.
>
>> I would argue that module_init() should be the default; it implies
>> no dependencies on the initialization, and it's a common pattern.
>
> To summarize briefly, module_init forces everything into one
> initcall priority bin
That's a feature. Everything should be in one bin unless there's reason
to specify; once you've specified, it's almost impossible to change
because our system is now so complicated.
module_init() says "I don't care".
> , it encourages people to write module_exit
> functions that are never used
Then write a checker. It's not that hard for kbuild to show stuff that
can never be a module, I'm sure.
>, and it can make the code appear
> inconsistent with the Kconfig and/or Makefile settings. So I'd
> hope you'd agree that there is value in not using module_init
> in code that can never be modular.
On the other hand, people cut & paste like crazy, so it makes sense to
have them all use module_init() and not build non-modular code, because
most code is a module.
Since this is total bikeshed, you can apply this yourself:
Acked-by: Rusty Russell <rusty@rustcorp.com.au> (disagree, but hey...)
Cheers,
Rusty.
prev parent reply other threads:[~2015-08-28 0:39 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
2015-08-26 13:41 ` Paul Gortmaker
2015-08-27 4:13 ` Rusty Russell [this message]
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=87bndtid1f.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.