Message-ID: <CAMuHMdVd==KLP3Uu5Gw9tDosEwrKD8LW2C1pvteARY_N_By3xQ@mail.gmail.com>
Date:	Tue, 21 Jan 2014 15:36:48 +0100
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Linux/m68k" <linux-m68k@...r.kernel.org>
Subject: Re: don't use module_init in non-modular ... (was: Re: [PATCH] m68k:
 don't use module_init in non-modular mvme16x/rtc.c code)

On Mon, Jan 20, 2014 at 4:27 AM, Paul Gortmaker
<paul.gortmaker@...driver.com> wrote:
>> > 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.
>>
>> The word "module" has different meanings: it can be a "loadable kernel module",
>> or just a "code module". include/linux/init.h seems to agree with this:
>
> I think for most people, "module" means an actual "foo.ko" that can be
> fed to insmod.  And it is generated by code that is controlled by a
> tristate config.  Otherwise, sure "init/main.c" is a "code module" and
> so is every C file, making the distinction meaningless.  Further....
>
>>     /**
>>      * module_init() - driver initialization entry point
>>      * @x: function to be run at kernel boot time or module insertion
>>      *
>>      * module_init() will either be called during do_initcalls() (if
>>      * builtin) or at module insertion time (if a module).  There can only
>>      * be one per module.
>
> ...I don't see how you can use the above comments to imply agreement
> with your interpretation.  The above refers to what is done with

"function to be run at kernel boot time".

> tristate (i.e. modular) code in the =y case and the =m case.  I'd be
> reluctant to think it meant anything about non-modular code in general.
> Moving this block inside of module.h helps clarify that, as well.
>
>>      */
>>     #define module_init(x)  __initcall(x);
>>
>> I can understand you want to restrict "module_init()" to real loadable
>> modules, but "device_initcall()" sounds like a real bad name or this.
>
> It is an existing name, it is part of the infrastructure added to
> replace the non-prioritized __initcall, and what is wrong with a
> non-modular device driver calling device_initcall()?  I don't see the
> badness.  Seems like quite a good fit, actually.  Just like having
> non-modular specific arch code calling arch_initcall() etc. etc.

OK, if no one else objects, please go on.

>> Furthermore, many places that contain always compiled-in code and
>> currently only use module_init() should probably start using module_exit()
>> as well, to do the proper cleanups to make kexec work.
>
> Always compiled in code that uses module_init() blocks us from ever
> properly making use of the prioritied initcall levels, because they
> all land in one bucket.  See the mm and kernel commits making use of
> priority levels in mm/ and kernel/ in akpm's mmotm tree for examples.

Making use of prioritized initcall levels would require different/new
initcall variants anyway.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists