On 17.09.25 07:43, Eugen Hristev wrote:
On 9/17/25 00:16, Thomas Gleixner wrote:
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.
It would have been great if we could have had that discussion in the
previous thread.
I didn't like what I saw in v2. In particular, having subsystems fiddle
with kmemdump specifics.
I prefer if we can find a way to not have subsystems to that.
I agree. I explained the solution to David. He wanted to un-static
everything. I disagreed.
Some other subsystem wants to have access to this information. I agree
that exposing these variables as r/w globally is not ideal.
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?
--
Cheers
David / dhildenb
