public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Matt Turner <mattst88@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	linux-alpha <linux-alpha@vger.kernel.org>
Subject: Re: [PATCH 06/15] alpha: don't use module_init for non-modular core code
Date: Fri, 29 May 2015 11:15:38 -0400	[thread overview]
Message-ID: <5568829A.5080109@windriver.com> (raw)
In-Reply-To: <CAEdQ38GBZkOuDb=Qu2ddXEV9B+q0F6f=fL3pTm13-r5WA3LHsA@mail.gmail.com>

On 2015-05-29 01:51 AM, Matt Turner wrote:
> On Thu, May 28, 2015 at 5:48 PM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
>> The srm console is always built in.  It will never be modular,
>> so using module_init as an alias for __initcall is rather
>> misleading.
>>
>> Fix this up now, so that we can relocate module_init from
>> init.h into module.h in the future.  If we don't do this, we'd
>> have to add module.h to obviously non-modular code, and that
>> would be a worse thing.
>>
>> Direct use of __initcall is discouraged, vs prioritized ones.
>> Use of device_initcall is consistent with what __initcall
>> maps onto, and hence does not change the init order, making the
>> impact of this change zero.   Should someone with real hardware
>> for boot testing want to change it later to arch_initcall or
>> console_initcall, they can do that at a later date.
>>
>> Cc: Richard Henderson <rth@twiddle.net>
>> Reviewed-by: Richard Henderson <rth@twiddle.net>
>> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
>> Cc: Matt Turner <mattst88@gmail.com>
>> Cc: linux-alpha@vger.kernel.org
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>
> I included this in my pull request to Linus that went upstream
> yesterday. Thanks!

OK, thanks - I'll drop it from here if/when I rebase onto the
4.1-rc6 pending on Sunday.  If I drop it now I'll risk introducing
a bisect failure for alpha, since my current baseline of 4.1-rc5
doesn't have this now-upstream change from the old original series.

Paul.
--

>


  reply	other threads:[~2015-05-29 15:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-29  0:47 [PATCH 00/15] Replace module_init with device_initcall in non modules Paul Gortmaker
2015-05-29  0:47 ` [PATCH 01/15] x86: don't use module_init in non-modular intel_mid_vrtc.c Paul Gortmaker
2015-05-29  0:48 ` [PATCH 02/15] x86: don't use module_init in non-modular devicetree.c code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 03/15] powerpc: use device_initcall for registering rtc devices Paul Gortmaker
2015-05-29  0:48 ` [PATCH 04/15] powerpc: don't use module_init in non-modular 83xx suspend code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 05/15] arm: don't use module_init in non-modular mach-vexpress/spc.c code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 06/15] alpha: don't use module_init for non-modular core code Paul Gortmaker
2015-05-29  5:51   ` Matt Turner
2015-05-29 15:15     ` Paul Gortmaker [this message]
2015-05-29  0:48 ` [PATCH 07/15] ia64: don't use module_init for non-modular core kernel/mca.c code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 08/15] ia64: don't use module_init in non-modular sim/simscsi.c code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 09/15] cris: don't use module_init for non-modular core intmem.c code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 10/15] parisc: don't use module_init for non-modular core pdc_cons code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 11/15] parisc64: don't use module_init for non-modular core perf code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 12/15] mn10300: don't use module_init in non-modular flash.c code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 13/15] sh: don't use module_init in non-modular psw.c code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 14/15] xtensa: don't use module_init for non-modular core network.c code Paul Gortmaker
2015-05-29  0:48 ` [PATCH 15/15] drivers/clk: don't use module_init in clk-nomadik.c which is non-modular Paul Gortmaker

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=5568829A.5080109@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mattst88@gmail.com \
    --cc=rth@twiddle.net \
    /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