Just like the other generic debug options, move the irq one to
'Kernel hacking' menu.
Signed-off-by: Changbin Du <[email protected]>
---
kernel/irq/Kconfig | 12 ------------
lib/Kconfig.debug | 11 +++++++++++
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index f92d9a687372..4684c44e0390 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -123,18 +123,6 @@ config SPARSE_IRQ
out the interrupt descriptors in a more NUMA-friendly way. )
If you don't know what to do here, say N.
-
-config GENERIC_IRQ_DEBUGFS
- bool "Expose irq internals in debugfs"
- depends on DEBUG_FS
- default n
- ---help---
-
- Exposes internal state information through debugfs. Mostly for
- developers and debugging of hard to diagnose interrupt problems.
-
- If you don't know what to do here, say N.
-
endmenu
config GENERIC_IRQ_MULTI_HANDLER
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 5960e2980a8a..c2fb63b4263b 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2142,6 +2142,17 @@ config IO_STRICT_DEVMEM
If in doubt, say Y.
+config GENERIC_IRQ_DEBUGFS
+ bool "Expose irq internals to userspace via debugfs"
+ depends on DEBUG_FS
+ default n
+ ---help---
+
+ Exposes internal state information through debugfs. Mostly for
+ developers and debugging of hard to diagnose interrupt problems.
+
+ If you don't know what to do here, say N.
+
source "arch/$(SRCARCH)/Kconfig.debug"
endmenu # Kernel hacking
--
2.20.1
On Sun, 1 Sep 2019, Changbin Du wrote:
> Just like the other generic debug options, move the irq one to
> 'Kernel hacking' menu.
Why?
Kernel hacking is a inscrutable mess where you can waste a lot of time to
find what you are looking for.
If I want to debug interrupts then having the option right there where all
other interrupt related configuration is makes tons of sense.
I would be less opposed to this when the kernel hacking menu would be
halfways well structured, but you just chose another random place for that
option which is worse than what we have now.
Thanks,
tglx
On Sun, Sep 01, 2019 at 08:23:02AM +0200, Thomas Gleixner wrote:
> On Sun, 1 Sep 2019, Changbin Du wrote:
>
> > Just like the other generic debug options, move the irq one to
> > 'Kernel hacking' menu.
>
> Why?
>
> Kernel hacking is a inscrutable mess where you can waste a lot of time to
> find what you are looking for.
>
yes, the 'kernel hacking' menu has many items now and are not well structured.
Let me see if it can be improved.
> If I want to debug interrupts then having the option right there where all
> other interrupt related configuration is makes tons of sense.
>
> I would be less opposed to this when the kernel hacking menu would be
> halfways well structured, but you just chose another random place for that
> option which is worse than what we have now.
>
We already have an irq debug option CONFIG_DEBUG_SHIRQ here. Maybe we can group
them into a submenu.
> Thanks,
>
> tglx
>
>
>
--
Cheers,
Changbin Du
On Sun, 1 Sep 2019 18:10:33 +0800
Changbin Du <[email protected]> wrote:
> On Sun, Sep 01, 2019 at 08:23:02AM +0200, Thomas Gleixner wrote:
> > On Sun, 1 Sep 2019, Changbin Du wrote:
> >
> > > Just like the other generic debug options, move the irq one to
> > > 'Kernel hacking' menu.
> >
> > Why?
> >
> > Kernel hacking is a inscrutable mess where you can waste a lot of time to
> > find what you are looking for.
> >
> yes, the 'kernel hacking' menu has many items now and are not well structured.
> Let me see if it can be improved.
>
> > If I want to debug interrupts then having the option right there where all
> > other interrupt related configuration is makes tons of sense.
> >
> > I would be less opposed to this when the kernel hacking menu would be
> > halfways well structured, but you just chose another random place for that
> > option which is worse than what we have now.
> >
> We already have an irq debug option CONFIG_DEBUG_SHIRQ here. Maybe we can group
> them into a submenu.
DEBUG_SHIRQ is extremely different from GENERIC_IRQ_DEBUGFS. The former
is a test option, verifying that endpoint drivers have a correct
behaviour. The latter is a dump of the kernel internals, which is
mostly for people dealing with the internals of the IRQ subsystem.
Preserving this distinction between the users of the IRQ API on one
side and the debugging of the IRQ subsystem on the other is important.
Moving these two things close together could make it even more confusing
for the users (who usually do not need to mess with the IRQ subsystem's
internals...).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On Sun, Sep 01, 2019 at 11:49:36AM +0100, Marc Zyngier wrote:
> On Sun, 1 Sep 2019 18:10:33 +0800
> Changbin Du <[email protected]> wrote:
>
> > On Sun, Sep 01, 2019 at 08:23:02AM +0200, Thomas Gleixner wrote:
> > > On Sun, 1 Sep 2019, Changbin Du wrote:
> > >
> > > > Just like the other generic debug options, move the irq one to
> > > > 'Kernel hacking' menu.
> > >
> > > Why?
> > >
> > > Kernel hacking is a inscrutable mess where you can waste a lot of time to
> > > find what you are looking for.
> > >
> > yes, the 'kernel hacking' menu has many items now and are not well structured.
> > Let me see if it can be improved.
> >
> > > If I want to debug interrupts then having the option right there where all
> > > other interrupt related configuration is makes tons of sense.
> > >
> > > I would be less opposed to this when the kernel hacking menu would be
> > > halfways well structured, but you just chose another random place for that
> > > option which is worse than what we have now.
> > >
> > We already have an irq debug option CONFIG_DEBUG_SHIRQ here. Maybe we can group
> > them into a submenu.
>
> DEBUG_SHIRQ is extremely different from GENERIC_IRQ_DEBUGFS. The former
> is a test option, verifying that endpoint drivers have a correct
> behaviour. The latter is a dump of the kernel internals, which is
> mostly for people dealing with the internals of the IRQ subsystem.
>
> Preserving this distinction between the users of the IRQ API on one
> side and the debugging of the IRQ subsystem on the other is important.
> Moving these two things close together could make it even more confusing
> for the users (who usually do not need to mess with the IRQ subsystem's
> internals...).
>
IMHO, these are two distinct irq *debug* options. If we prefer
preserving current position, please skip this patch. Thanks.
> Thanks,
>
> M.
> --
> Without deviation from the norm, progress is not possible.
--
Cheers,
Changbin Du