[lkml]   [2014]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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
<> 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.



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

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

 \ /
  Last update: 2014-01-21 16:21    [W:0.095 / U:3.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site