[PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.

Jason Baron jbaron at akamai.com
Wed Aug 3 20:13:05 UTC 2022



On 8/3/22 15:56, jim.cromie at gmail.com wrote:
> On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie <jim.cromie at gmail.com> wrote:
>>
> 
>> Hi Jason, Greg, DRM-folk,
>>
>> This adds 'typed' "class FOO" support to dynamic-debug, where 'typed'
>> means either DISJOINT (like drm debug categories), or VERBOSE (like
>> nouveau debug-levels).  Use it in DRM modules: core, helpers, and in
>> drivers i915, amdgpu, nouveau.
>>
> 
> This revision fell over, on a conflict with something in drm-MUMBLE
> 
> Error: patch https://urldefense.com/v3/__https://patchwork.freedesktop.org/api/1.0/series/106427/revisions/2/mbox/__;!!GjvTz_vk!UCPl5Uf32cDVwwysMTfaLwoGLWomargFXuR8HjBA3xsUOjxXHXC5hneAkP4iWK91yc-LjjJxWW89-51Z$ 
> not applied
> Applying: dyndbg: fix static_branch manipulation
> Applying: dyndbg: fix module.dyndbg handling
> Applying: dyndbg: show both old and new in change-info
> Applying: dyndbg: reverse module walk in cat control
> Applying: dyndbg: reverse module.callsite walk in cat control
> Applying: dyndbg: use ESCAPE_SPACE for cat control
> Applying: dyndbg: let query-modname override actual module name
> Applying: dyndbg: add test_dynamic_debug module
> Applying: dyndbg: drop EXPORTed dynamic_debug_exec_queries
> 
> Jason,
> those above are decent maintenance patches, particularly the drop export.
> It would be nice to trim this unused api this cycle.

Hi Jim,

Agreed - I was thinking the same thing. Feel free to add
Acked-by: Jason Baron <jbaron at akamai.com> to those first 9.



> 
> Applying: dyndbg: add class_id to pr_debug callsites
> Applying: dyndbg: add __pr_debug_cls for testing
> Applying: dyndbg: add DECLARE_DYNDBG_CLASSMAP
> Applying: kernel/module: add __dyndbg_classes section
> Applying: dyndbg: add ddebug_attach_module_classes
> Applying: dyndbg: validate class FOO by checking with module
> Applying: dyndbg: add drm.debug style bitmap support
> Applying: dyndbg: test DECLARE_DYNDBG_CLASSMAP, sysfs nodes
> Applying: doc-dyndbg: describe "class CLASS_NAME" query support
> Applying: doc-dyndbg: edit dynamic-debug-howto for brevity, audience
> Applying: drm_print: condense enum drm_debug_category
> Applying: drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.
> Applying: drm_print: interpose drm_*dbg with forwarding macros
> Applying: drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro
> Using index info to reconstruct a base tree...
> M drivers/gpu/drm/Kconfig
> M drivers/gpu/drm/Makefile
> Falling back to patching base and 3-way merge...
> Auto-merging drivers/gpu/drm/Makefile
> Auto-merging drivers/gpu/drm/Kconfig
> CONFLICT (content): Merge conflict in drivers/gpu/drm/Kconfig
> error: Failed to merge in the changes.
> 
> 
> Before I resend, I should sort out that possible conflict
> which tree is patchwork applied upon ?
> 
> or was it just transient ? after 5.19 I rebased a copy onto drm-next/drm-next,
> and there was nothing to fix - I will revisit presently..


Not sure, if it's a minor conflict maybe Greg KH can sort it when
he pulls it in? If not yeah might be important to rebase first...Greg?

Thanks,

-Jason


More information about the dri-devel mailing list