The added paragraph is slightly process oriented, rather than in language of guarantees; I thought the implications were clear enough.
It does perhaps undersell the selectivity gained with string class_names; only drm/* would sanely register DRM_UT_CORE etc, so doing multiple "module {drm*,amdgpu,i915}" queries is unnecessary.
Signed-off-by: Jim Cromie jim.cromie@gmail.com --- Documentation/admin-guide/dynamic-debug-howto.rst | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index a89cfa083155..01ca6f635dcc 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -35,6 +35,7 @@ Dynamic debug has even more useful features: - line number (including ranges of line numbers) - module name - format string + - class string (as known by each module)
* Provides a debugfs control file: ``<debugfs>/dynamic_debug/control`` which can be read to display the complete list of known debug @@ -142,6 +143,7 @@ against. Possible keywords are::: 'file' string | 'module' string | 'format' string | + 'class' string | 'line' line-range
line-range ::= lineno | @@ -203,6 +205,15 @@ format format "nfsd: SETATTR" // a neater way to match a format with whitespace format 'nfsd: SETATTR' // yet another way to match a format with whitespace
+class + The given class_name is validated against each module, which may + have registered a list of known class_names. If the class_name is + found for a module, callsite matching and adjustment proceeds. + Examples:: + + class DRM_UT_KMS # unless DRM wants different + class JUNK # silent non-match + line The given line number or range of line numbers is compared against the line number of each ``pr_debug()`` callsite. A single