From: Nick Alcock <hidden> Date: 2022-12-06 20:03:28
On 6 Dec 2022, Geert Uytterhoeven uttered the following:
On Mon, Dec 5, 2022 at 5:34 PM Nick Alcock [off-list ref] wrote:
quoted
Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations in
non-modules will cause modprobe to misidentify their containing object
file as a module when it is not, which might cause it to spuriously fail
when trying to load something that is built in to the kernel. They
also cause misconstruction of modules.builtin.objs, leading to incorrect
output in kallmodsyms (notating things as being in modules when they
actually cannot be built as a module at all).
Automatically identified with the new tristate checker, and purged with
sed and a subsequent make allmodconfig to double-check.
Signed-off-by: Nick Alcock <redacted>
I can (sort of) agree with the MODULE_LICENSE(), as it duplicates the
SPDX-License-Identifier at the top.
However, you don't explain why it is a good thing to remove the
MODULE_{AUTHOR,DESCRIPTION}, too. This is useful information, in an
easy-to-parse format.
I was concerned about that, but I kinda thought they went together and
it would be neater to take them out in one go -- but I'd be happy to
keep them in and only drop MODULE_LICENSE.
Moreover, many of the affected drivers might be converted into modules
in the near or far future.
If the presence of these causes issues for the tooling, perhaps the
tooling can be fixed instead?
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 -- but if the
thing is no longer a standalone entity at all I'm not sure what meaning
it could possibly have).
--
NULL && (void)
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
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.
Arnd
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2022-12-07 05:04:08
On Tue, Dec 06, 2022 at 10:02:30PM +0100, Arnd Bergmann wrote:
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.
Luis
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2022-12-07 05:10:24
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
On Wed, Dec 7, 2022 at 2:04 PM Luis Chamberlain [off-list ref] 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.
If we have a bool driver 'foo.ko' in modules.builtin,
'modprobe foo' will not fail where you expect it will fail.
Is it so important to make this strict?
I do not think so.
What is a point for a user to realize
"Oh, I did not know foo cannot be compiled as a module"
Re-read the commit description of
bc081dd6e9f622c73334dc465359168543ccaabf
The motivation of module.builtin is to know the functionality 'foo'
is available (via built-in or module, whatever).
In this sense, having always-builtin entries in module.builtin is OK.
I do not see any sense in the tooling mess in this patch set.
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.
I do not want to revert it.
and I do not want this series in the mainline.
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.
Luis