Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Jim Cromie <jim.cromie@gmail.com>
To:     jbaron@akamai.com, gregkh@linuxfoundation.org,
        linux-kernel@vger.kernel.org
Cc:     daniel.vetter@ffwll.ch, seanpaul@chromium.org, robdclark@gmail.com,
        linux@rasmusvillemoes.dk, joe@perches.com,
        dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
        intel-gvt-dev@lists.freedesktop.org,
        intel-gfx@lists.freedesktop.org, Jim Cromie <jim.cromie@gmail.com>
Subject: [PATCH 0/5] dyndbg add exclusive class support
Date:   Thu, 10 Mar 2022 21:47:51 -0700
Message-Id: <20220311044756.425777-1-jim.cromie@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Greg, Jason,

Please consider these for char/misc or linux-next/soon/mumble.

This patchset adds exclusive class support to dyndbg, allowing it to
directly represent drm's debug_category.

It is the dyndbg half of:
https://lore.kernel.org/lkml/20220217034829.64395-1-jim.cromie@gmail.com/

The DRM half of that patchset uses this support to reimplement
drm.debug on dyndbg, and uses its callsite patching to avoid the
runtime checking done by drm_debug_enabled().

Background:

In the past, various extensions to dyndbg/pr_debug have been proposed,
none seemed to gain any consensus.  This list is certainly incomplete.

https://lore.kernel.org/lkml/20200609104604.1594-1-stanimir.varbanov@linaro.org/

pr_levels was discussed around this patchset, in revs 3,4,5
This search helps:
	s:venus: s:dynamic f:stanimir.varbanov@linaro.org

IMO, pr_levels suffers from implied meaning between the levels: 2 > 1.
In contrast, DRM has logically disjoint categories, and is implemented
in an enum (despite its flag/mask values, a micro-optimization).

https://lore.kernel.org/lkml/20210813151734.1236324-1-jim.cromie@gmail.com/

That patchset used pr_debug in DRM, and prepended "drm:kms:" etc to
the format strings so each category was selectable; "format drm:kms:"
in the query.  This worked, but it made the format config-dependent,
and was hard to explain without undue "artifact".


So this patchset adds .class_id field (4-bits) to dynamic-debug
callsites, and 'class N' query/command support to select upon it.
Existing callsites and queries get .class_id=15, so 0-14 are available
for use by the client (DRM wants 0-10).

The DRM patchset then:
. renumbers drm_debug_category to fit into the 4-bit .class_id
  the new enumerations *are* the bit-positions in drm/parameters/debug.
. adapts the category-macro layer to use _CLS macros, mapping categories.
. adds macro layer under the category-macro layer
  which wraps drm_*dbg inside a dyndbg Factory macro
. uses DEFINE_DYNAMIC_DEBUG_CLASSBITS to tie to __drm_debug
  callbacks ref the var, so drm_debug_enabled(cat) just works.

Jim Cromie (5):

dyndbg: fix static_branch manipulation
  fixes a latent bug, before a 2nd "enable" flag exposes it.

dyndbg: add class_id field and query support
  will allow (with that drm patchset):
  #> # turn on DRM_ATOMIC in amdgpu
  #> echo module amdgpu class 4 +p > /proc/dynamic_debug/control
  #> # turn on DRM_CORE in drm
  #> echo module drm class 0 +p > /proc/dynamic_debug/control

dyndbg: add DEFINE_DYNAMIC_DEBUG_CLASSBITS macro
  adds macro & callbacks to support drm.debug bitmap
  #> echo 4 > /sys/module/drm/parameters/debug

dyndbg: drop EXPORTed dynamic_debug_exec_queries
  unused yet, obsoleted by 2,3

dyndbg: show both old and new in change-info
  minor debug improvement


 .../admin-guide/dynamic-debug-howto.rst       |   7 +
 include/linux/dynamic_debug.h                 | 111 ++++++++++---
 lib/dynamic_debug.c                           | 150 ++++++++++++++----
 3 files changed, 213 insertions(+), 55 deletions(-)

-- 
2.35.1