Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 29 Oct 2021 17:19:52 +0100
From:   Daniel Thompson <daniel.thompson@linaro.org>
To:     Qian Cai <quic_qiancai@quicinc.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] configs: Introduce debug.config for CI-like setup
Message-ID: <20211029161952.u4g7vutcz3qd57lo@maple.lan>
References: <20211029034434.24553-1-quic_qiancai@quicinc.com>
 <20211029093115.6ychbe56pnebzi43@maple.lan>
 <e0301a5f-a2c7-eedb-90b1-1d6d631fcc47@quicinc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e0301a5f-a2c7-eedb-90b1-1d6d631fcc47@quicinc.com>
Precedence: bulk

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.