lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 29 Oct 2021 17:19:52 +0100
From:   Daniel Thompson <>
To:     Qian Cai <>
Cc:     Andrew Morton <>,
        Masahiro Yamada <>,,
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.


Powered by blists - more mailing lists