Re: [Intel-gfx] [PATCH v6 00/57] DYNDBG: opt-in class'd debug for modules, use in drm.

Greg KH
2022-09-07T15:08:46Z

On Sun, Sep 04, 2022 at 03:40:37PM -0600, Jim Cromie wrote:
> hi Greg, Jason, DRM-folk, Steven,
>
> If Im not too late for linux-next in this cycle, heres V6. Diffs are minor:
>
> - rebased onto e47eb90a0a9a (tag: next-20220901, linux-next/master)
> gets past Kconfig conflict, same for drm-tip.
> - uint debug_level, not ulong. to fit nouveau.
> - -1 on param-read-back, to match prev write val.
> - added back tracefs parts, missing from -V5
> updated for tracing/events: Add __vstring() and __assign_vstr() helper macros
> no decorations-lite in TP_printk, do it right later.
> - commit-msg tweaks
>
> Theres also new RFC stuff with the potential to reduce the size of the
> __dyndbgs section by 20%. Not ready for prime time, or linux-next,
> but I hope compelling.
>
> FEATURE DESCRIPTION
>
> dyndbg provides DECLARE_DYNAMIC_DEBUG_CLASSMAP() which allows module
> authors to declare "good" class-names, of 4 types.
>
> DYNAMIC_DEBUG_CLASSMAP(drm_debug_classes,
> DD_CLASS_TYPE_DISJOINT_BITS, offset,
> "DRM_UT_CORE",
> "DRM_UT_DRIVER",
> "DRM_UT_KMS",
> "DRM_UT_PRIME",
> "DRM_UT_ATOMIC",
> "DRM_UT_VBL",
> "DRM_UT_STATE",
> "DRM_UT_LEASE",
> "DRM_UT_DP",
> "DRM_UT_DRMRES");
>
> That usage authorizes dyndbg to set class'd pr_debugs accordingly:
>
> echo class DRM_UT_CORE +p > /proc/dynamic_debug/control
> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
>
> Because the DRM modules declare the same classes, they each authorize
> dyndbg with the same classnames, which allows dyndbg to effect changes
> to its selected class'd prdbgs.
>
> Opting in by using the macro effectively privatizes the limited
> 63-classes available per module; only modules which share classnames
> must coordinate their use of the common range, and they can
> independently use the remaining id-space.
>
> Other dyndbg filtering pertains too, so single sites can be selected.
>
>
> 4 DD_CLASS_TYPE_*_*s determine 2 behaviors:
>
> DISJOINT bits are independent, like drm.debug categories
> LEVELs 3>2, turns on level-2, like nouveau debug-levels
> NUM/BITS numeric input, bitmap if disjoint, else 0-32.
> NAMES accept proper names, like DRM_UT_CORE
>
> Dyndbg provides param-callbacks which enforce those behaviors:
>
> # DISJOINT_BITS
> echo 0x03 > /sys/module/drm/parameters/debug
>
> # LEVEL_NUM
> echo 3 > /sys/module/drm/nouveau/debug-mumble*
>
> # DISJOINT_NAMES
> echo +DRM_UT_CORE,+DRM_UT_KMS,-DRM_UT_DRIVER > /sys/module/drm/parameters/debug_categories
>
> # LEVEL_NAMES
> echo NV_TRACE > /sys/module/nouveau/parameters/debug-mumble*
>
> That design choice is allowed cuz verbosity is always attached to a
> (user visible) interface, and theres no reason not to put the
> implementation there (in the callback). It also considerably
> simplifies things; ddebug_change can treat class_id's as disjoint,
> period.
>

I've applied the first 21 patches in this series to my
driver-core-testing branch, and if 0-day doesn't blow up on it, I'll
move it to my -next branch tomorrow and it will get a wider testing
range in the linux-next releases.

Feel free to rebase the rest of the series on top of my tree and
resubmit after addressing Daniel's comments.

thanks,

greg k-h