On 3/13/26 3:20 PM, Greg Kroah-Hartman wrote:
> Module "versions" do not make sense as the kernel is built all at once,
> the "version" is the overall kernel version number, so modules can not
> really be described as having a unique version given that they rely on
> the infrastructure of the whole kernel.
>
> For now, just make this an "empty" define, to keep existing code
> building properly as the tree is slowly purged of the use of this over
> time.
>
> This macro will be removed entirely in the future when there are no
> in-tree users.
I share a similar sentiment that module versions set by MODULE_VERSION()
are not particularly useful for in-tree modules and the macro is often
used unnecessarily. However, I don't think this patch takes the best
approach to phase it out.
The file Documentation/ABI/stable/sysfs-module documents
/sys/module/<MODULENAME>/version as a stable ABI. Searching for
'^MODULE_VERSION' in v7.0-rc4 shows 600 uses of the macro. My concern is
that if any of these modules has a userspace part that checks the
version, this patch could potentially break users' systems.
I believe it would be safer to start by removing individual uses of
MODULE_VERSION(). That way, we can also learn if we're missing any use
cases for having module versions.
The original patch "Add a MODULE_VERSION macro" [1] from 2004 doesn't
say much about the motivation for adding module versions, but it does
mention that they should be accessible via sysfs. That was implemented
a year later in commit c988d2b28454 ("[PATCH] modules: add version and
srcversion to sysfs") [2], which primarily discusses use cases related
to DKMS, and to administrators + tech support needing to know what is
actually loaded on the system. For the latter, I believe srcversion (or
something similar) should be sufficient.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux-fullhistory.git/commit/?id=466ae11966ae380eb5e10cdf323e140d824fa10c
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c988d2b2845495373f666a381d354a7f80981d62
--
Thanks,
Petr
