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

On Fri, Sep 17, 2021 at 02:30:09PM -0600, jim.cromie@gmail.com wrote:

On Fri, Sep 17, 2021 at 1:50 PM Jason Baron [off-list ref] wrote:

quoted

On 9/13/21 6:24 PM, Andrew Halaney wrote:

quoted

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 <redacted>
Suggested-by: Jim Cromie <jim.cromie@gmail.com>
---
  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.

I dont think params can be a loadable module, so its not a great
example of this.
it should be one that "everyone" knows is usually loaded.

conversely, bare dyndbg example should have only builtin modules,
then the contrast between 2 forms is most evident.

Thank you both for the feedback, good points.

Does something like:

    // Enable pr_debugs in the btrfs module (can be builtin or loadable)
    btrfs.dyndbg="+p"
    // enable pr_debugs in all files under init/
    // and the function parse_one, #cmt is stripped
    dyndbg="file init/* +p #cmt ; func parse_one +p"

Work for you both? I think that makes the advantages of $module.dyndbg=
more clear and makes the usage of dyndbg= stick to strictly builtins.
If so I'll respin this patch in v3 of the series.

Thanks,
Andrew

quoted

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

Thanks,

-Jason

quoted

+    // 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"