[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