Messages in this thread | | | Subject | Re: [PATCH v2 3/3] Documentation: dyndbg: Improve cli param examples | From | Jason Baron <> | Date | Fri, 17 Sep 2021 17:54:35 -0400 |
| |
On 9/17/21 4:53 PM, Andrew Halaney wrote: > 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 <jbaron@akamai.com> wrote: >>> >>> >>> 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@redhat.com> >>>> 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.
Fine with me.
Thanks,
-Jason
> > Thanks, > Andrew > >>> 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"
| |