Re: [PATCH v2 3/3] Documentation: dyndbg: Improve cli param examples

From: Jason Baron
Date: Fri Sep 17 2021 - 16:14:17 EST




On 9/13/21 6:24 PM, Andrew Halaney wrote:
Jim pointed out that using $module.dyndbg= is always a more flexible
choice for using dynamic debug on the command line. The $module.dyndbg
style is checked at boot and handles if $module is a builtin. If it is
actually a loadable module, it is handled again later when the module is
loaded.

If you just use dyndbg="module $module +p" dynamic debug is only enabled
when $module is a builtin.

It was recommended to illustrate wildcard usage as well.

Signed-off-by: Andrew Halaney <ahalaney@xxxxxxxxxx>
Suggested-by: Jim Cromie <jim.cromie@xxxxxxxxx>
---
Documentation/admin-guide/dynamic-debug-howto.rst | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst
index d0911e7cc271..4bfb23ed64ec 100644
--- a/Documentation/admin-guide/dynamic-debug-howto.rst
+++ b/Documentation/admin-guide/dynamic-debug-howto.rst
@@ -357,7 +357,10 @@ Examples
Kernel command line: ...
// see whats going on in dyndbg=value processing
dynamic_debug.verbose=1
- // enable pr_debugs in 2 builtins, #cmt is stripped
- dyndbg="module params +p #cmt ; module sys +p"
+ // Enable pr_debugs in the params builtin
+ params.dyndbg="+p"

If we are going out of our way to change this to indicate that it works for builtin and modules, it seems like the comment above should reflect that? IE, something like this?

'// Enable pr_debugs in the params module or if params is builtin.

The first two patches look fine to me, so if you agree maybe just re-spin this one?

Thanks,

-Jason

+ // enable pr_debugs in all files under init/
+ // and the function pc87360_init_device, #cmt is stripped
+ dyndbg="file init/* +p #cmt ; func pc87360_init_device +p"
// enable pr_debugs in 2 functions in a module loaded later
pc87360.dyndbg="func pc87360_init_device +p; func pc87360_find +p"