From: Hans de Goede <redacted>
Date: Mon, 21 Nov 2022 09:12:41 +0100

Hi,

On 11/21/22 00:45, Masahiro Yamada wrote:

quoted

On Mon, Nov 21, 2022 at 5:55 AM Hans de Goede [off-list ref] wrote:

[...]

quoted

quoted

So nack from me for this patch, since I really don't see
it adding any value.

This does have a value.

This clarifies the ownership of the common.o,
in other words, makes KBUILD_MODNAME deterministic.


If an object belongs to a module,
KBUILD_MODNAME is defined as the module name.

If an object is always built-in,
KBUILD_MODNAME is defined as the basename of the object.



Here is a question:
if common.o is shared by two modules intel_skl_int3472_discrete
and intel_skl_int3472_tps68470, what should KBUILD_MODNAME be?


I see some patch submissions relying on the assumption that
KBUILD_MODNAME is unique.
We cannot determine KBUILD_MODNAME correctly if an object is shared
by multiple modules.

+1

quoted

BTW, this patch is not the way I suggested.
The Suggested-by should not have been there
(or at least Reported-by)

(to Masahiro)

Ah, you're right, sorry. Will replace all the tags to Reported-by,
that would look more correct.

quoted

You argued "common.o is tiny", so I would vote for
making them inline functions, like


https://lore.kernel.org/linux-kbuild/20221119225650.1044591-2-alobakin@pm.me/T/#u (local)

Yes just moving the contents of common.c to static inline helpers in common.h
would be much better.

Sure, why not. There probably are more of shared object files which
would feel better being static inlines in the series, will see.

If someone creates such a patch, please do not forget to Cc
platform-driver-x86@vger.kernel.org

Got it, sure. get_maintainer.pl dropped a wall on me, so I was
picking stuff manually from it and missed that one.

Regards,

Hans

[...]

quoted

quoted

quoted

Ditto. And the same to all your patches.

Thanks,
Olek