Re: [PATCH v2] configs: Introduce debug.config for CI-like setup

[Daniel Thompson]

On Fri, Oct 29, 2021 at 09:57:31AM -0400, Qian Cai wrote:
> On 10/29/21 5:31 AM, Daniel Thompson wrote:
> > Does this config need comments at the top of the file describing its 
> > "mission"?  Put another way, the comments in the description about
> > where these config options come from seem too important leave buried
> > in the git history. They are important to understanding what it is
> > for.
> > 
> > I know this the other configs do not have big header comments. However
> > the existing configs are closer to self-describing. debug.config simply does not explain what the file does in the way xen.config can! People
> > will surely want to add their "favourite" debug options[1] and those
> > contributors would benefit from clues on what the configs here are
> > intended for.
> 
> Daniel, (small world, isn't it? Enjoyed your OpenEmbedded lessons in the
> past.), That's a good point. I personally got used to "git log". I'll
> add some comments there.

Hello again.

In this case the small world comes about because "debug" is of the
keywords I use to filter LKML ;-)


> >> +# Keep alphabetically sorted.
> > 
> > This results in 119 line file that is more-or-less impossible to
> > comment. It alphabetic really the best way to maintain something
> > containing so much subjective judgement?
> 
> I thought about ordering those in different subject groups, but then
> realized it might be an overkill for an only one-hundred line file. Most
> of the options would have a prefix like _LOCKDEP_, _KMEMLEAK_ etc, so
> they are subject-related close together even sorted alphabetically.

My feedback came about because, in alphabetic form, it is not easy to
see which ftrace tracers are enabled (because they are named
CONFIG_<feature>_TRACER they appear all over the place).


> I don't really have a strong option on this matter though. We could
> organize it like in Kconfig sections if people like that way better
> although it could have a potential overhead to sync with future
> Kconfig.debug in the future as their places and names change from time
> to time.
> 
> # printk and dmesg options
> # Compile-time checks and compiler options
> # Generic Kernel Debugging Instruments
> # Memory Debugging
> # Scheduler Debugging
> # Lock Debugging (spinlocks, mutexes, etc...)
> # Debug kernel data structures
> # RCU Debugging

Personally I'd favour this. It really depends on how often it is
read/changed by uesrs rather than just consumed by the build system.
Personally I think this will be read quite often.


Daniel.