On Sun, Sep 01, 2019 at 11:49:36AM +0100, Marc Zyngier wrote: > On Sun, 1 Sep 2019 18:10:33 +0800 > Changbin Du <changbin...@gmail.com> 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
