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-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
