[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a52u9jyl.ffs@tglx>
Date: Tue, 16 Sep 2025 23:16:34 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Eugen Hristev <eugen.hristev@...aro.org>, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, andersson@...nel.org,
pmladek@...e.com, rdunlap@...radead.org, corbet@....net, david@...hat.com,
mhocko@...e.com
Cc: tudor.ambarus@...aro.org, mukesh.ojha@....qualcomm.com,
linux-arm-kernel@...ts.infradead.org, linux-hardening@...r.kernel.org,
jonechou@...gle.com, rostedt@...dmis.org, linux-doc@...r.kernel.org,
devicetree@...r.kernel.org, Eugen Hristev <eugen.hristev@...aro.org>
Subject: Re: [RFC][PATCH v3 09/16] genirq/irqdesc: Have nr_irqs as non-static
On Tue, Sep 16 2025 at 23:10, Thomas Gleixner wrote:
> On Fri, Sep 12 2025 at 18:08, Eugen Hristev wrote:
>> nr_irqs is required for debugging the kernel, and needs to be
>> accessible for kmemdump into vmcoreinfo.
>
> That's a patently bad idea.
>
> Care to grep how many instances of 'nr_irqs' variables are in the
> kernel?
>
> That name is way too generic to be made global.
Aside of that there is _ZERO_ justification to expose variables globaly,
which have been made file local with a lot of effort in the past.
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.
Thanks
tglx
Powered by blists - more mailing lists