From: Luis Chamberlain <mcgrof@kernel.org>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
Nick Alcock <nick.alcock@oracle.com>,
Alan Maguire <alan.maguire@oracle.com>,
Masahiro Yamada <masahiroy@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Jiri Olsa <olsajiri@gmail.com>,
Elena Zannoni <elena.zannoni@oracle.com>
Subject: Re: [PATCH v4 2/3] kbuild, kconfig: generate offset range data for builtin modules
Date: Tue, 18 Jun 2024 11:57:38 -0700 [thread overview]
Message-ID: <ZnHYooN7o2JEgsWA@bombadil.infradead.org> (raw)
In-Reply-To: <20240614171428.968174-3-kris.van.hees@oracle.com>
On Fri, Jun 14, 2024 at 01:14:27PM -0400, Kris Van Hees wrote:
> The offset range data for builtin modules is generated using:
> - modules.builtin: associates object files with module names
> - vmlinux.map: provides load order of sections and offset of first member
> per section
> - vmlinux.o.map: provides offset of object file content per section
> - .*.cmd: build cmd file with KBUILD_MODFILE and KBUILD_MODNAME
What tests do we have to ensure this is working correctly and not
spewing out lies? What proactive mechanisms do we have to verify the
semantics won't change, or to warn at build time that this awk script
will break upon new changes? Is this just best effort? Is that good
enough? Why?
Luis
next prev parent reply other threads:[~2024-06-18 18:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 17:14 [PATCH v4 0/3] Generate address range data for built-in modules Kris Van Hees
2024-06-14 17:14 ` [PATCH v4 1/3] kbuild: add mod(name,file)_flags to assembler flags for module objects Kris Van Hees
2024-06-14 17:46 ` Steven Rostedt
2024-06-14 18:10 ` Kris Van Hees
2024-06-14 18:26 ` Steven Rostedt
2024-08-14 14:26 ` Kris Van Hees
2024-06-14 17:14 ` [PATCH v4 2/3] kbuild, kconfig: generate offset range data for builtin modules Kris Van Hees
2024-06-14 18:57 ` Kris Van Hees
2024-06-18 18:57 ` Luis Chamberlain [this message]
2024-08-14 14:24 ` Kris Van Hees
2024-06-14 17:14 ` [PATCH v4 3/3] module: add install target for modules.builtin.ranges Kris Van Hees
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=ZnHYooN7o2JEgsWA@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=elena.zannoni@oracle.com \
--cc=kris.van.hees@oracle.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mhiramat@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nick.alcock@oracle.com \
--cc=olsajiri@gmail.com \
--cc=rostedt@goodmis.org \
/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;
as well as URLs for NNTP newsgroup(s).