Messages in this thread | | | Date | Fri, 29 Oct 2021 17:19:52 +0100 | From | Daniel Thompson <> | Subject | Re: [PATCH v2] configs: Introduce debug.config for CI-like setup |
| |
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.
| |