On Mon, Mar 16, 2026 at 10:37:38AM +0100, Petr Pavlu wrote:
> 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.
sysfs use is ALWAYS "if the file is not there, the userspace tool should
keep working". How would userspace every do something different if a
module version flag is not there, that is not how a kernel driver should
ever be attempting to communicate with userspace as to what the api is,
or is not.
And as the module version does not even work for any stable kernel
release, it's kind of proof that userspace does not rely on this.
> 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.
Sure, I'll make up a patch to drop all 700 uses, but how is that much
different? :)
> 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 because we were just exporting all of the module information in
sysfs, not due to us attempting to do anything special with that info in
userspace other than "hey we have an attribute, let's export it!"
> 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.
And does dkms actually do anything with this sysfs value? At quick
glance, I couldn't see anything.
thanks,
greg k-h
