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.
