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

[Qian Cai <quic_qiancai@quicinc.com>]

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.

>> +# 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. 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