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

[Daniel Thompson]

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.