Re: [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Tue, Sep 06, 2022 at 09:18:09PM +0200, Daniel Vetter wrote: > On Fri, Aug 12, 2022 at 08:03:47AM +0200, Greg KH wrote: > > On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote: > > > On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote: > > > > > > > > > > > > On 8/3/22 15:56, jim.cro...@gmail.com wrote: > > > > > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie > > > > > 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 to those first 9. > > > > > > Does Greg KH usually pick up dyndbg patches or someone else or do I need > > > to do something? Would be great to get some movement here since -rc1 goes > > > out and merging will restart next week. > > > > Yes, I can take these into my tree after -rc1 is out. > > [uncovering from an absolutely impressive cascade of holes :-(] > > Did this happen and I can stop worrying here? I'd like to make sure these > drm debug infra improvements keep moving. I didn't take these, and I think I saw a 6th series sent: https://lore.kernel.org/r/20220904214134.408619-1-jim.cro...@gmail.com If you ack them, I will pick them up. thanks, greg k-h
Re: [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Wed, Sep 07, 2022 at 07:47:10AM +0200, Greg KH wrote: > On Tue, Sep 06, 2022 at 09:18:09PM +0200, Daniel Vetter wrote: > > On Fri, Aug 12, 2022 at 08:03:47AM +0200, Greg KH wrote: > > > On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote: > > > > On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote: > > > > > > > > > > > > > > > On 8/3/22 15:56, jim.cro...@gmail.com wrote: > > > > > > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie > > > > > > 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 to those first 9. > > > > > > > > Does Greg KH usually pick up dyndbg patches or someone else or do I need > > > > to do something? Would be great to get some movement here since -rc1 > > > > goes > > > > out and merging will restart next week. > > > > > > Yes, I can take these into my tree after -rc1 is out. > > > > [uncovering from an absolutely impressive cascade of holes :-(] > > > > Did this happen and I can stop worrying here? I'd like to make sure these > > drm debug infra improvements keep moving. > > I didn't take these, and I think I saw a 6th series sent: > https://lore.kernel.org/r/20220904214134.408619-1-jim.cro...@gmail.com > > If you ack them, I will pick them up. Hm here we only talked about the first 9 or so patches from the series, do you still want my ack on those? Acked-by: Daniel Vetter Since yeah I do like the direction of this :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Fri, Aug 12, 2022 at 08:03:47AM +0200, Greg KH wrote: > On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote: > > On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote: > > > > > > > > > On 8/3/22 15:56, jim.cro...@gmail.com wrote: > > > > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie 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 to those first 9. > > > > Does Greg KH usually pick up dyndbg patches or someone else or do I need > > to do something? Would be great to get some movement here since -rc1 goes > > out and merging will restart next week. > > Yes, I can take these into my tree after -rc1 is out. [uncovering from an absolutely impressive cascade of holes :-(] Did this happen and I can stop worrying here? I'd like to make sure these drm debug infra improvements keep moving. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote: > On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote: > > > > > > On 8/3/22 15:56, jim.cro...@gmail.com wrote: > > > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie 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 to those first 9. > > Does Greg KH usually pick up dyndbg patches or someone else or do I need > to do something? Would be great to get some movement here since -rc1 goes > out and merging will restart next week. Yes, I can take these into my tree after -rc1 is out. thanks, greg k-h
Re: [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote: > > > On 8/3/22 15:56, jim.cro...@gmail.com wrote: > > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie 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 to those first 9. Does Greg KH usually pick up dyndbg patches or someone else or do I need to do something? Would be great to get some movement here since -rc1 goes out and merging will restart next week. -Daniel > > > > > > > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On 8/3/22 15:56, jim.cro...@gmail.com wrote: > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie 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 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
Re: [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie 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://patchwork.freedesktop.org/api/1.0/series/106427/revisions/2/mbox/ 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. 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..
[PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
Oof, v3 had 2 copies renumbered and intermingled. Resending w/o the crud.
v4 missed dri-devel & patchwork, sending there now. with doc tweak per Bagas.
Its also at https://github.com/jimc/linux.git, in the dyn-drm-trc branch.
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.
If a module is using class'd prdbgs (pr_debug_class, dev_dbg_class, or
adapted drm_dbg_) or similar in its code, it can "opt in" to
allow dyndbg to manipulate those class'd prdebugs, by declaring in a
c-file:
DECLARE_DYNDBG_CLASSMAP(drm_debug_classes,
DD_CLASS_TYPE_DISJOINT, 0,
"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");
// how-to stringify __va_args inside the macro ?
By doing this, a module tells dyndbg that it:
- is using class-ids [0..N] in prdbg callsites
0..N are the numeric values of DRM_UT_CORE..DRM_UT_DRMRES
- wants to refer to them by class-names [0..N]
- is mapping those names to those class-ids
- expects users to enable them via >control or >parameter/knob
Then, a user can enable the prdbgs by their class:
:#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
And with another 3-line bitmap param decl/init, wrapping the
drm_debug_classes var in a module-param-cb:
:#> echo 0x1 > /sys/module/drm/parameters/debug
and optionally:
:#> echo +DRM_UT_CORE,-DRM_UT_KMS \
> /sys/module/drm/parameters/debug_cats
DYNAMIC_DEBUG gets:
new .class_id:5 field in struct _ddebug (callsite record) big enough
to represent drm_debug_category (after squeezing) defaults to 31 for
all existing prdbgs. class_id is also used to, or any reasonable
number of verbose levels (30 is impractical, istm).
classmaps (as declared by macro above) are in their own linker
section, and are loaded by kernel/module, and handled by add_module,
which attaches classmaps to their module's ddebug table.
ddebug_change() handles a class FOO query by validating that FOO is
known by each module in the loop. The query is skipped unless the
module knows FOO, so no changes are possible w/o a good classname.
Without class FOO in a query/command, only ids=31 can be changed by
that query. This protects all class'd prdbgs from changes by old,
class-less user queries.
With this support, the module opt-in approach means that:
- modules declare classnames they like, meaningful names, DRM_UT_*
these are numbered [0..N]
- modules call pr_debug_class(N, "fmt..",...)
or drm_dbg(CAT, "fmt..",...) - same form.
- class-id space, while limited:0-30, is private to each module
- "class FOO" is only way to enable a class'd prdbg
- unrelated modules use 0..N separately, for different purposes.
- modules "share" classnames by separate decls (uses of macro)
all drm modules reuse the above declaration.
then they respond together to a >control
4 CLASS_TYPES are defined; they split behavior on 2 factors:
1. independent bits vs related:(X sysknob ambiguity
as was case when both were accepted on same knob
- narrower interfaces
uint is uint
- can defer SYMBOLIC handling, but keep the enums.
it has no users ...
- can later add 2 more ENUMS allowing both inputs
in separate VERBOSE & DISJOINT choices
then authors choice if they want to accept mixed input
- can enumerate "wierd" relations if needed
DISJOINT|VERBOSE should cover everything I can forsee
but theres room for DD_CLASS_TYPE_STOCHASTIC (over the garage)
NB: DISJOINT v RELATED cover the space; there is no semi-related. The
relation could differ from (xhttps://lore.kernel.org/lkml/20220516225640.3102269-1-jim.cro...@gmail.com/
summary of diffs:
- rebased on 5.19-rc6 to pick up kernel/module changes
- tracfs bits now use __vstring, __vstr_assign, from S.Rostedt
- 4 class-map-types - as outlined above
now supports VERBOSE semantics, WIP nouveau integration.
v2 became the DISJOINT use case
Lots of API-ish surface area here *RFC*
- class-maps now in section("__dyndbg_classes")
class FOO queries are available at earlyboot / module-load
drop (un)?register_classes()
- test-dynamic-debug module
tests the 4 CLASS-TYPES
good place to bikeshed / paintshop the API
- nouveau - start poking - WIP
NV_PRINT -> dev_dbg (creates 632 prdbgs, but not class'd)
VERBOSE classes declared to see how they "fit", unused yet.
Summary:
- plenty of new stuff here.
- plenty of new API surface area.
-
