<div dir="ltr"><div dir="ltr"><div>hi Sanjaya,</div><div><br></div><div>thanks for reading this. Let me back up and ask a bigger question,</div><div><br></div><div>How much of this is excessive explanation?</div><div><br></div><div>most devs would look for a test-*, or a sample/* or an existing use,</div><div>And the new macros already have their kdoc where it belongs,</div><div>so this mostly restates api, and might not belong in admin-guide ??</div><div><br></div><div>I now know enough to look for test-*s </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 31, 2024 at 11:02 PM Bagas Sanjaya <<a href="mailto:bagasdotme@gmail.com" target="_blank">bagasdotme@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Oct 31, 2024 at 02:44:03AM -0600, Jim Cromie wrote:<br>
> +The main difference from the others: class'd prdbgs must be named to<br>
> +be changed. This protects them from generic overwrite:<br>
> +<br>
> + # IOW this cannot undo any DRM.debug settings<br>
> + :#> ddcmd -p<br>
> +<br>
> +So each class must be enabled individually (no wildcards):<br>
> +<br>
> + :#> ddcmd class DRM_UT_CORE +p<br>
> + :#> ddcmd class DRM_UT_KMS +p<br>
> + # or more selectively<br>
> + :#> ddcmd class DRM_UT_CORE module drm +p<br>
> +<br>
> +Or the legacy/normal (more convenient) way:<br>
> +<br>
> + :#> echo 0x1ff > /sys/module/drm/parameters/debug<br>
<br>
Format command sequences as literal code blocks (like in the rest of docs):<br></blockquote><div><br></div><div>I dont know what this means (yet), will do.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
---- >8 ----<br>
diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst<br>
index 3068d134fcc6d9..a826b972461fe5 100644<br>
--- a/Documentation/admin-guide/dynamic-debug-howto.rst<br>
+++ b/Documentation/admin-guide/dynamic-debug-howto.rst<br>
@@ -388,19 +388,19 @@ domain-oriented names. This complements the nested-scope keywords:<br>
module, file, function, line.<br>
<br>
The main difference from the others: class'd prdbgs must be named to<br>
-be changed. This protects them from generic overwrite:<br>
+be changed. This protects them from generic overwrite::<br>
<br>
# IOW this cannot undo any DRM.debug settings<br>
:#> ddcmd -p<br>
<br>
-So each class must be enabled individually (no wildcards):<br>
+So each class must be enabled individually (no wildcards)::<br>
<br>
:#> ddcmd class DRM_UT_CORE +p<br>
:#> ddcmd class DRM_UT_KMS +p<br>
# or more selectively<br>
:#> ddcmd class DRM_UT_CORE module drm +p<br>
<br>
-Or the legacy/normal (more convenient) way:<br>
+Or the legacy/normal (more convenient) way::<br>
<br>
:#> echo 0x1ff > /sys/module/drm/parameters/debug<br>
<br>
> +DYNDBG_CLASSMAP_DEFINE(var,type,_base,classnames) - this maps<br>
> +classnames onto class-ids starting at _base, it also maps the<br>
> +names onto CLASSMAP_PARAM bits 0..N.<br>
> +<br>
> +DYNDBG_CLASSMAP_USE(var) - modules call this to refer to the var<br>
> +_DEFINEd elsewhere (and exported).<br>
<br>
Shouldn't these DYNDBG_CLASSMAP_* descriptions be list?<br></blockquote><div><br></div><div><br></div><div>I dont know what you mean here.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> +<br>
> +Classmaps are opt-in: modules invoke _DEFINE or _USE to authorize<br>
> +dyndbg to update those classes. "class FOO" queries are validated<br>
> +against the classes, this finds the classid to alter; classes are not<br>
> +directly selectable by their classid.<br>
> +<br>
> +There are 2 types of classmaps:<br>
> +<br>
> + DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, like DRM.debug<br>
> + DD_CLASS_TYPE_LEVEL_NUM: classes are relative, ordered (V3 > V2)<br>
<br>
For lists, format them as such otherwise these will be outputted as long<br>
paragraphs:<br>
<br>
---- >8 ----<br>
diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst<br>
index a826b972461fe5..c70e34f01822a2 100644<br>
--- a/Documentation/admin-guide/dynamic-debug-howto.rst<br>
+++ b/Documentation/admin-guide/dynamic-debug-howto.rst<br>
@@ -408,9 +408,10 @@ Dynamic Debug Classmap API<br>
==========================<br>
<br>
DRM.debug is built upon:<br>
- ~23 macros, all passing a DRM_UT_* constant as arg-1.<br>
- ~5000 calls to them, across drivers/gpu/drm/*<br>
- bits in /sys/module/drm/parameters/debug control all DRM_UT_* together<br>
+<br>
+- 23 macros, all passing a DRM_UT_* constant as arg-1.<br>
+- 5000 calls to them, across ``drivers/gpu/drm/*`` bits in<br>
+ ``/sys/module/drm/parameters/debug`` control all DRM_UT_* together<br>
<br>
The const short ints are good for optimizing compilers; a classmaps<br>
design goal was to keep that. So basically .classid === category.<br>
@@ -438,8 +439,8 @@ directly selectable by their classid.<br>
<br>
There are 2 types of classmaps:<br>
<br>
- DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, like DRM.debug<br>
- DD_CLASS_TYPE_LEVEL_NUM: classes are relative, ordered (V3 > V2)<br>
+- ``DD_CLASS_TYPE_DISJOINT_BITS``: classes are independent, like DRM.debug<br>
+- ``DD_CLASS_TYPE_LEVEL_NUM``: classes are relative, ordered (V3 > V2)<br>
<br>
DYNDBG_CLASSMAP_PARAM - modelled after module_param_cb, it refers to a<br>
DEFINEd classmap, and associates it to the param's data-store. This<br>
<br>
Thanks.<br>
<br>
-- <br>
An old man doll... just what I always wanted! - Clara<br>
</blockquote></div></div>
</div>