Re: dynamic_debug: enabled vs FLAGS_PRINT, more filtering tricks.

[Jason Baron]

On Wed, Jul 27, 2011 at 04:04:53PM -0600, Jim Cromie wrote:
> On Mon, Jul 25, 2011 at 3:42 PM, Jim Cromie <jim.cromie@xxxxxxxxx> wrote:
> >
> >
> > This patchset extends dynamic-debug facility to allow
> > use of pr_debug() within a loadable module's module_init()
> > function.  Query/rules can be given on the boot-line,
> > and are saved to a pending list if they cannot be applied
> > immediately.  Later, when the module is being loaded, the
> > pending list is scanned, and matching rules are applied.
> > Thus pr_debug() calls in the module's initialization function
> > are active when it is invoked.
> >
> 
> latest version (including fixes for Barts comments) is at
> git://github.com/jimc/linux-2.6.git
> in dyndbg-next branch.
> 
> Is there a reason for having both enabled and _DPRINTK_FLAGS_PRINT  ?
> 
> struct _ddebug {
> ...
> #define _DPRINTK_FLAGS_PRINT   (1<<0)
> ...
> #define _DPRINTK_FLAGS_DEFAULT 0
> 	unsigned int flags:8;
> 	char enabled;
> } __attribute__((aligned(8)));
> 
> as things stand, you can disable print flag with " -p "
> but the call-site may still be enabled, ie [tmlf]
> 
> New ability to clear all flags via  " =_ " handles this, but ..
> 
> OTOH,         if (descriptor.enabled)
> becomes    if (descriptor.flags & _DPRINTK_FLAGS_PRINT)
> 
> then current flags can be filtered to enable/disable previously
> selected callsites.
>   echo " t+p " > /dbg/dynamic_debug/control
> 
> This suggests that unused flags can be named (x,y,z for example)
> then used expressly for marking arbitrary sets of callsites,
> and toggling their enabled/disabled states.
> 
>   echo " x+p " > /dbg/dynamic_debug/control
>   echo " y-p " > /dbg/dynamic_debug/control
>   echo " z+p " > /dbg/dynamic_debug/control

'enabled' is an artifact from when we only had only flag: 'p'. Now, that
we have multiple flags, it probably does make more sense to use 'p' to
control whether there is printing. Since as you pointed out, it makes it
easier to disable things with just " -p".

Thanks,

-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/