[PATCH 2/2] nvme: keyring: fix conditional compilation
Arnd Bergmann
arnd at arndb.de
Fri Oct 27 02:14:24 PDT 2023
On Fri, Oct 27, 2023, at 11:08, Hannes Reinecke wrote:
> On 10/27/23 10:56, Christoph Hellwig wrote:
>> On Fri, Oct 27, 2023 at 10:54:42AM +0200, Hannes Reinecke wrote:
>>>> I don't really mind the link order, for these cases I usually add a
>>>> comment to the Makefile so that people don't accidentally change it.
>>>
>>> Point is not that it has to be initialized first, point is it has to be
>>> initialized only _once_.
>>
>> module_init ensure it is only initialized once except for the case where
>> the module is unloaded and reloaded, in which case you actually do need
>> to initialize it again.
>>
> So if I do this:
>
> obj-$(CONFIG_MOD1) += mod1.o mod-common.o
> obj-$(CONFIG_MOD2) += mod2.o mod-common.o
>
> and mod-common contains a 'module_init()' and a 'module_exit()'
> function, what happens if I load mod2 after mod1?
> And what happens if I unload mod2, but keep mod1?
In the syntax above, you get three loadable modules:
mod1.ko, mod2.ko and mod-common.ko. Loading either
mod1.ko or mod2.ko leads to mod-common.ko getting loaded
and intialized first, and it remains loaded until both
mod1 and mod2 get removed. If one of the two symbols is
set to =y, then mod-common.o becomes part of vmlinux,
gets initialized first and cannot get removed.
This is different from the invalid example
obj-$(CONFIG_MOD1) += mod1_module.o
obj-$(CONFIG_MOD2) += mod2_module.o
mod1_module-y += mod1.o mod-common.o
mod2_module-y += mod2.o mod-common.o
which is probably what you were thinking of. In this
case, we'd get two modules mod1_module.ko and mod2_module.ko,
with mod-common.o getting compiled and linked separately
into each one if they are both =m, or a single copy
linked into vmlinux if they are both =y. Kbuild now
warns if you attempt to do this, because it causes
a number of problems.
Arnd
More information about the Linux-nvme
mailing list