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
