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
