linux-kernel - Re: [PATCH v3 1/7] Documentation: dynamic-debug: Add description of level bitmask

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <20200610070949.GB1923109@kroah.com>
Date:   Wed, 10 Jun 2020 09:09:49 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-btrfs@...r.kernel.org, linux-acpi@...r.kernel.org,
        netdev@...r.kernel.org, Jason Baron <jbaron@...mai.com>,
        Jonathan Corbet <corbet@....net>,
        Jim Cromie <jim.cromie@...il.com>
Subject: Re: [PATCH v3 1/7] Documentation: dynamic-debug: Add description of
 level bitmask

On Tue, Jun 09, 2020 at 11:35:31PM -0700, Joe Perches wrote:
> On Wed, 2020-06-10 at 08:31 +0200, Greg Kroah-Hartman wrote:
> > On Tue, Jun 09, 2020 at 09:58:07AM -0700, Joe Perches wrote:
> > > On Tue, 2020-06-09 at 13:16 +0200, Greg Kroah-Hartman wrote:
> > > > What is wrong with the existing control of dynamic
> > > > debug messages that you want to add another type of arbitrary grouping
> > > > to it? 
> > > 
> > > There is no existing grouping mechanism.
> > 
> > info/warn/err/dbg is what I am referring to.
> > 
> > > Many drivers and some subsystems used an internal one
> > > before dynamic debug.
> > > 
> > > $ git grep "MODULE_PARM.*\bdebug\b"|wc -l
> > > 501
> > 
> > Yes, and it's horrid and needs to be cleaned up, not added to.
> 
> Or unified so driver authors have a standardized mechanism
> rather than reinventing or doing things differently.

But each "level" you all come up with will be intrepreted differently
per driver, causing total confusion (like we have today.)  Try to make
it better by just removing that mess.

> > In the beginning, yes, adding loads of different types of debugging
> > options to a driver is needed by the author, but by the time it is added
> > to the kernel, all of that should be able to be removed and only a
> > single "enable debug" should be all that is needed.
> 
> No one does that.

We did that for USB drivers a decade ago, it can be done.

greg k-h