linux-kernel - Re: [PATCH v2 20/24] dyndbg: WIP towards debug-print-class based callsite controls

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: <20200617093154.v7mf5355faa4c7ob@holly.lan>
Date:   Wed, 17 Jun 2020 10:31:54 +0100
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Petr Mladek <pmladek@...e.com>, Jim Cromie <jim.cromie@...il.com>,
        jbaron@...mai.com, linux-kernel@...r.kernel.org,
        akpm@...uxfoundation.org, gregkh@...uxfoundation.org,
        linux@...musvillemoes.dk
Subject: Re: [PATCH v2 20/24] dyndbg: WIP towards debug-print-class based
 callsite controls

On Tue, Jun 16, 2020 at 02:05:27PM -0700, Joe Perches wrote:
> On Tue, 2020-06-16 at 15:45 +0200, Petr Mladek wrote:
> > On Sat 2020-06-13 09:57:34, Jim Cromie wrote:
> > > There are *lots* of ad-hoc debug printing solutions in kernel,
> > > this is a 1st attempt at providing a common mechanism for many of them.
> > 
> > I agree that it might make sense to provide some common mechanism.
> []
> > My problem with this approach is that it is too generic. Each class
> > would have different meaning in each subsystem.
> > 
> > It might help to replace any existing variants. But it would be hard
> > for developers debugging the code. They would need to study/remember
> > the meaning of these groups for particular subsystems. They would
> > need to set different values for different messages.
> > 
> > Could you please provide more details about the potential users?
> > Would be possible to find some common patterns and common
> > meaning of the groups?
> 
> I doubt the utility of common patterns.
> Verbosity is common but groupings are not.
> 
> Look at the DRM patterns vs other groups.

I've seen drm.debug mentioned a couple of times but the comments about
it seem to only learn part of what is shows us.

drm.debug is a form of common grouping but it acts at a sub-system level
rather then whole system (and gives a whole sub-system enable/disable).
This is where grouping makes most sense.

The result is that drm.debug is easy to document, both in official
kernel docs and in other resources (like the arch distro documentation).
Having controls that are easy to document makes them easy to find and
thus sub-system grouping leads directly to higher quality bug reports.


Daniel.