On Tue, Dec 06, 2022 at 09:03:52PM -0800, Luis Chamberlain wrote:

On Tue, Dec 06, 2022 at 10:02:30PM +0100, Arnd Bergmann wrote:

quoted

On Tue, Dec 6, 2022, at 21:03, Nick Alcock wrote:

quoted

On 6 Dec 2022, Geert Uytterhoeven uttered the following:
Only MODULE_LICENSE invokes MODULE_FILE and thus ends up introducing a
KBUILD_MODOBJS entry that triggers things going wrong iff not a module:
so only it needs to go out (or be replaced with a variant that doesn't
invoke MODULE_FILE, if you want to keep the license in too --

That sounds like a better alternative

quoted

but if the thing is no longer a standalone entity at all I'm not sure
what meaning it could possibly have).

As far as I can tell, the general trend is to make more things modules,
so there is a good chance that these come back eventually. If the
information in the MODULE_LICENSE field isn't wrong, I would just
leave it in there.

Tooling today uses it though to make a deterministic call on if something
*can* be a module. In particular after commit 8b41fc4454e ("kbuild: create
modules.builtin without Makefile.modbuiltin or tristate.conf") we rely on
the module license tag to generate the modules.builtin file. This in
turn is used to allow modprobe to *not* fail when trying to load a module
which is built-in.

So we can't just disable the tag for when the code is built-in as *want*
to carry it when modules are built-in, that is the point, to help
userspace with this determination.

I don't think we want to revert 8b41fc4454e as it means we'd force Kbuild to
traverse the source tree twice.

Geert's point was not keeping MODULE_LICENSE() but instead the other
MODULE_*() crap for things which are not modules in case in the future
code becomes a module...

But I don't see the point in keeping things around just in case, if we
want to keep things simple. Just use the SPDX license tag for the license.

Or if you really want to keep it just make it an *eye-sore*, and comment it out.

I don't see why at build-time we should suffer.

  Luis