From: Luis Chamberlain <mcgrof@kernel.org>
To: Nick Alcock <nick.alcock@oracle.com>
Cc: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>,
masahiroy@kernel.org, linux-modules@vger.kernel.org,
linux-kernel@vger.kernel.org, arnd@arndb.de,
akpm@linux-foundation.org, eugene.loh@oracle.com,
kris.van.hees@oracle.com, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v9 4/8] kallsyms: introduce sections needed to map symbols to built-in modules
Date: Tue, 15 Nov 2022 11:58:34 -0800 [thread overview]
Message-ID: <Y3PvavbJDZsQCiuQ@bombadil.infradead.org> (raw)
In-Reply-To: <87edu4uz7z.fsf@esperi.org.uk>
On Tue, Nov 15, 2022 at 01:25:04PM +0000, Nick Alcock wrote:
> (I'm also a bit miffed because people are worrying about 10K of
> overhead at the same time as a patch is going in adding half a meg ;)
You are missing that the reason why your patch lacks much traction is
it lacks a clear *use* case. It has nothing to do with space. The cover
letter can be really summarized in a condensed way to get the point accross
to just include the text on your first paragraph you had at Plumbers:
https://lpc.events/event/16/contributions/1379/
This gets the point accross well.
The rest of the cover letter is just pure noise and gets me lost.
But for instance, when I reviewed the patch for adding ranges, your
cover letter describes the *justification*, the *why* to do that, but
the patch does not at all.
Please make sure that your commits describe *why* clearly. Please get
a bit of help from your team to condense to the cover letter to only
include what is needed if someone is reading the patchset for the
very first time.
And then users.. we need users clearly documented, who the heck is
using this or wants this / is going to use it and why.
Luis
next prev parent reply other threads:[~2022-11-15 19:58 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 13:41 [PATCH PING v9] kallsyms: reliable symbol->address lookup with /proc/kallmodsyms Nick Alcock
2022-11-09 13:41 ` [PATCH v9 1/8] kbuild: bring back tristate.conf Nick Alcock
2022-11-10 3:56 ` Luis Chamberlain
2022-11-09 13:41 ` [PATCH v9 2/8] kbuild: add modules_thick.builtin Nick Alcock
2022-11-10 3:58 ` Luis Chamberlain
2022-11-11 13:47 ` Nick Alcock
2022-11-11 14:03 ` Nick Alcock
2022-11-11 15:12 ` Luis Chamberlain
2022-11-14 17:49 ` Nick Alcock
2022-11-15 21:21 ` Luis Chamberlain
2022-11-21 15:21 ` Nick Alcock
2022-11-21 19:12 ` Luis Chamberlain
2022-11-21 19:18 ` Luis Chamberlain
2022-11-21 21:14 ` Nick Alcock
2022-11-09 13:41 ` [PATCH v9 3/8] kbuild: generate an address ranges map at vmlinux link time Nick Alcock
2022-11-13 3:02 ` Luis Chamberlain
2022-11-14 16:48 ` Nick Alcock
2022-11-15 21:22 ` Luis Chamberlain
2022-11-16 16:06 ` Nick Alcock
2022-11-09 13:41 ` [PATCH v9 4/8] kallsyms: introduce sections needed to map symbols to built-in modules Nick Alcock
2022-11-13 3:15 ` Luis Chamberlain
2022-11-14 17:04 ` Nick Alcock
2022-11-15 11:47 ` Leizhen (ThunderTown)
2022-11-15 13:25 ` Nick Alcock
2022-11-15 19:58 ` Luis Chamberlain [this message]
2022-11-15 20:36 ` Luis Chamberlain
2022-11-09 13:41 ` [PATCH v9 5/8] kallsyms: optimize .kallsyms_modules* Nick Alcock
2022-11-09 13:41 ` [PATCH v9 6/8] kallsyms: distinguish text symbols fully using object file names Nick Alcock
2022-11-09 13:41 ` [PATCH v9 7/8] kallsyms: add /proc/kallmodsyms for text symbol disambiguation Nick Alcock
2022-11-13 3:26 ` Luis Chamberlain
2022-11-14 16:57 ` Nick Alcock
2022-11-15 21:24 ` Luis Chamberlain
2022-11-09 13:41 ` [PATCH v9 8/8] perf: proof-of-concept kallmodsyms support Nick Alcock
-- strict thread matches above, loose matches on Subject: below --
2022-10-27 19:57 [PATCH v9] kallsyms: reliable symbol->address lookup with /proc/kallmodsyms Nick Alcock
2022-10-27 19:57 ` [PATCH v9 4/8] kallsyms: introduce sections needed to map symbols to built-in modules Nick Alcock
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=Y3PvavbJDZsQCiuQ@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=eugene.loh@oracle.com \
--cc=kris.van.hees@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nick.alcock@oracle.com \
--cc=rostedt@goodmis.org \
--cc=thunder.leizhen@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®