dynamic_debug: enabled vs FLAGS_PRINT, more filtering tricks.

[Jim Cromie]

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