From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Petr Pavlu <petr.pavlu@suse.com>
Cc: linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
Luis Chamberlain <mcgrof@kernel.org>,
Daniel Gomez <da.gomez@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Aaron Tomlin <atomlin@atomlin.com>,
Shyam Saini <shyamsaini@linux.microsoft.com>,
Kees Cook <kees@kernel.org>,
Thorsten Blum <thorsten.blum@linux.dev>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] module: remove MODULE_VERSION()
Date: Mon, 16 Mar 2026 11:03:03 +0100 [thread overview]
Message-ID: <2026031630-linseed-powdered-a0d1@gregkh> (raw)
In-Reply-To: <d622c70a-f79a-4215-84fb-c5de0a8f6ce5@suse.com>
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
next prev parent reply other threads:[~2026-03-16 10:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 14:20 [PATCH] module: remove MODULE_VERSION() Greg Kroah-Hartman
2026-03-13 15:46 ` Greg Kroah-Hartman
2026-03-13 17:28 ` Sami Tolvanen
2026-03-14 10:22 ` Christophe Leroy (CS GROUP)
2026-03-16 8:58 ` Christoph Hellwig
2026-03-16 17:25 ` Sami Tolvanen
2026-03-16 10:48 ` Petr Pavlu
2026-03-13 17:07 ` Sami Tolvanen
2026-03-16 8:57 ` Christoph Hellwig
2026-03-16 9:37 ` Petr Pavlu
2026-03-16 10:03 ` Greg Kroah-Hartman [this message]
2026-03-17 12:50 ` Petr Pavlu
2026-03-27 12:27 ` Nam Cao
2026-03-27 12:44 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026031630-linseed-powdered-a0d1@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=atomlin@atomlin.com \
--cc=da.gomez@kernel.org \
--cc=hch@infradead.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=samitolvanen@google.com \
--cc=shyamsaini@linux.microsoft.com \
--cc=thorsten.blum@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox