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)

From: Geert Uytterhoeven
Date: Tue Jan 21 2014 - 09:37:01 EST


On Mon, Jan 20, 2014 at 4:27 AM, Paul Gortmaker
<paul.gortmaker@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/