From: Thomas Gleixner <tglx@linutronix.de>
To: David Hildenbrand <david@redhat.com>,
Eugen Hristev <eugen.hristev@linaro.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, andersson@kernel.org, pmladek@suse.com,
rdunlap@infradead.org, corbet@lwn.net, mhocko@suse.com
Cc: tudor.ambarus@linaro.org, mukesh.ojha@oss.qualcomm.com,
linux-arm-kernel@lists.infradead.org,
linux-hardening@vger.kernel.org, jonechou@google.com,
rostedt@goodmis.org, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [RFC][PATCH v3 09/16] genirq/irqdesc: Have nr_irqs as non-static
Date: Wed, 17 Sep 2025 16:10:07 +0200 [thread overview]
Message-ID: <87v7lh891c.ffs@tglx> (raw)
In-Reply-To: <2bd45749-e483-45ea-9c55-74c5ba15b012@redhat.com>
On Wed, Sep 17 2025 at 09:16, David Hildenbrand wrote:
> On 17.09.25 07:43, Eugen Hristev wrote:
>> On 9/17/25 00:16, Thomas Gleixner wrote:
>>> I pointed you to a solution for that and just because David does not
>>> like it means that it's acceptable to fiddle in subsystems and expose
>>> their carefully localized variables.
>
> It would have been great if we could have had that discussion in the
> previous thread.
Sorry. I was busy with other stuff and did not pay attention to that
discussion.
> Some other subsystem wants to have access to this information. I agree
> that exposing these variables as r/w globally is not ideal.
It's a nono in this case. We had bugs (long ago) where people fiddled
with this stuff (I assume accidentally for my mental sanity sake) and
caused really nasty to debug issues. C is a horrible language to
encapsulate stuff properly as we all know.
> I raised the alternative of exposing areas or other information through
> simple helper functions that kmemdump can just use to compose whatever
> it needs to compose.
>
> Do we really need that .section thingy?
The section thing is simple and straight forward as it just puts the
annotated stuff into the section along with size and id and I definitely
find that more palatable, than sprinkling random functions all over the
place to register stuff.
Sure, you can achieve the same thing with an accessor function. In case
of nr_irqs there is already one: irq_get_nr_irqs(), but for places which
do not expose the information already for real functional reasons adding
such helpers just for this coredump muck is really worse than having a
clearly descriptive and obvious annotation which results in the section
build.
The charm of sections is that they don't neither extra code nor stubs or
ifdeffery when a certain subsystem is disabled and therefore no
information available.
I'm not insisting on sections, but having a table of 2k instead of
hundred functions, stubs and whatever is definitely a win to me.
Thanks,
tglx
next prev parent reply other threads:[~2025-09-17 14:10 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-12 15:08 [RFC][PATCH v3 00/16] Introduce kmemdump Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 01/16] kmemdump: " Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 02/16] Documentation: Add kmemdump Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 03/16] kmemdump: Add coreimage ELF layer Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 04/16] Documentation: kmemdump: Add section for coreimage ELF Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 05/16] kernel/vmcore_info: Register dynamic information into Kmemdump Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 06/16] kmemdump: Introduce qcom-minidump backend driver Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 07/16] soc: qcom: smem: Add minidump device Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 08/16] init/version: Add banner_len to save banner length Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 09/16] genirq/irqdesc: Have nr_irqs as non-static Eugen Hristev
2025-09-16 21:10 ` Thomas Gleixner
2025-09-16 21:16 ` Thomas Gleixner
2025-09-17 5:43 ` Eugen Hristev
2025-09-17 7:16 ` David Hildenbrand
2025-09-17 14:10 ` Thomas Gleixner [this message]
2025-09-17 14:26 ` Eugen Hristev
2025-09-17 14:46 ` David Hildenbrand
2025-09-17 15:02 ` Eugen Hristev
2025-09-17 15:18 ` David Hildenbrand
2025-09-17 15:32 ` Eugen Hristev
2025-09-17 15:44 ` David Hildenbrand
2025-09-17 18:42 ` Thomas Gleixner
2025-09-17 19:03 ` David Hildenbrand
2025-09-18 8:23 ` Thomas Gleixner
2025-09-18 13:53 ` Eugen Hristev
2025-09-18 18:43 ` Randy Dunlap
2025-09-25 20:11 ` David Hildenbrand
2025-09-12 15:08 ` [RFC][PATCH v3 10/16] panic: Have tainted_mask " Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 11/16] mm/swapfile: Have nr_swapfiles " Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 12/16] printk: Register information into Kmemdump Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 13/16] sched: Add sched_get_runqueues_area Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 14/16] kernel/vmcoreinfo: Register kmemdump core image information Eugen Hristev
2025-09-12 15:08 ` [RFC][PATCH v3 15/16] kmemdump: Add Kinfo backend driver Eugen Hristev
2025-09-16 5:48 ` Alexey Klimov
2025-09-22 10:01 ` Tudor Ambarus
2025-09-12 15:08 ` [RFC][PATCH v3 16/16] dt-bindings: Add Google Kinfo Eugen Hristev
2025-09-14 11:56 ` Krzysztof Kozlowski
2025-09-12 15:56 ` [RFC][PATCH v3 00/16] Introduce kmemdump David Hildenbrand
2025-09-12 18:35 ` Eugen Hristev
2025-09-16 7:49 ` Mukesh Ojha
2025-09-16 15:25 ` Luck, Tony
2025-09-16 15:27 ` Eugen Hristev
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=87v7lh891c.ffs@tglx \
--to=tglx@linutronix.de \
--cc=andersson@kernel.org \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=devicetree@vger.kernel.org \
--cc=eugen.hristev@linaro.org \
--cc=jonechou@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mukesh.ojha@oss.qualcomm.com \
--cc=pmladek@suse.com \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tudor.ambarus@linaro.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).