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;
Subject: Re: [PATCH v2] configs: Introduce debug.config for CI-like setup
To:     Daniel Thompson <daniel.thompson@linaro.org>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        <linux-kbuild@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <20211029034434.24553-1-quic_qiancai@quicinc.com>
 <20211029093115.6ychbe56pnebzi43@maple.lan>
From:   Qian Cai <quic_qiancai@quicinc.com>
Message-ID: <e0301a5f-a2c7-eedb-90b1-1d6d631fcc47@quicinc.com>
Date:   Fri, 29 Oct 2021 09:57:31 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <20211029093115.6ychbe56pnebzi43@maple.lan>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


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