From: Will McVicker <willmcvicker@google.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jessica Yu <jeyu@kernel.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Saravana Kannan <saravanak@google.com>,
linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
kernel-team@android.com
Subject: Re: [PATCH v2 0/2] Adds support to capture module's SCM version
Date: Fri, 4 Dec 2020 10:13:56 -0800 [thread overview]
Message-ID: <X8p8ZK1sXQ2E7hSA@google.com> (raw)
In-Reply-To: <20201204075159.GA29752@infradead.org>
On Fri, Dec 04, 2020 at 07:51:59AM +0000, Christoph Hellwig wrote:
> I think your decription still shows absolutely no benefit for the
> kernel, so I'not sure why anyone would want to waste time on this.
Hi Christoph,
Did you get a chance to read my earlier responses regarding the uses for
in-tree modules?
The biggest benefit for the upstream community is being about to get the SCM
version for *any* module (including in-tree modules) in the initramfs via the
sysfs node. Currently there is no way to do that and there is no guarantee that
those modules in the initramfs were compiled with the running kernel. In fact,
running,
modinfo -F vermagic MODULENAME
will return an invalid vermagic string if the same module with different
vermagic strings exists in the initramfs and on disk because modinfo only looks
at the module on disk (not in memory).
The second most useful benefit goes hand-in-hand with MODVERSIONS. The purpose
of MODVERSIONS is to create a stable interface that allows one to update the
kernel and kernel modules (including in-tree modules) independently. So when
developers do update their kernels independently (think for security bug
fixes), the `scmversion` attribute guarantees developers that they can still
identify the modules' or kernel's SCM version.
I hope that helps. If not, then please let me know why these reasons "show
absolutely no benefit for the kernel?"
Thanks,
Will
next prev parent reply other threads:[~2020-12-04 18:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-21 1:16 [PATCH v1 0/2] Add support to capture external module's SCM version Will McVicker
2020-11-21 1:16 ` [PATCH v1 1/2] scripts/setlocalversion: allow running in a subdir Will McVicker
2020-11-21 1:16 ` [PATCH v1 2/2] modules: add scmversion field Will McVicker
2020-11-23 9:30 ` Greg KH
2020-11-23 9:32 ` Greg KH
2020-11-23 9:02 ` [PATCH v1 0/2] Add support to capture external module's SCM version Christoph Hellwig
2020-11-23 22:13 ` William Mcvicker
2020-11-24 9:31 ` Jessica Yu
2020-11-24 18:05 ` William Mcvicker
2020-11-24 18:12 ` Greg Kroah-Hartman
2020-11-24 18:31 ` William Mcvicker
2020-11-24 20:24 ` Greg Kroah-Hartman
2020-11-24 20:40 ` William Mcvicker
2020-11-24 20:45 ` Saravana Kannan
2020-11-25 1:05 ` [PATCH v2 0/2] Adds support to capture " Will McVicker
2020-11-25 1:05 ` [PATCH v2 1/2] scripts/setlocalversion: allow running in a subdir Will McVicker
2020-11-25 1:05 ` [PATCH v2 2/2] modules: add scmversion field Will McVicker
2020-12-07 15:31 ` Jessica Yu
2020-12-08 20:05 ` [PATCH v3 0/2] " Will McVicker
2020-12-08 20:05 ` [PATCH v3 1/2] scripts/setlocalversion: allow running in a subdir Will McVicker
2020-12-11 15:33 ` Jessica Yu
2020-12-16 22:08 ` Will McVicker
2020-12-08 20:05 ` [PATCH v3 2/2] modules: introduce the MODULE_SCMVERSION config Will McVicker
2020-12-04 0:36 ` [PATCH v2 0/2] Adds support to capture module's SCM version William Mcvicker
2020-12-04 7:51 ` Christoph Hellwig
2020-12-04 18:13 ` Will McVicker [this message]
2020-12-04 18:18 ` Christoph Hellwig
2020-12-04 18:20 ` Will McVicker
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=X8p8ZK1sXQ2E7hSA@google.com \
--to=willmcvicker@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jeyu@kernel.org \
--cc=kernel-team@android.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=saravanak@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.