[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfuBxx_cSTuYoJjLkrGX3kYMvgw4Ep+rEL2VDNv-Ti5PB1C4w@mail.gmail.com>
Date: Wed, 27 Jul 2011 16:04:53 -0600
From: Jim Cromie <jim.cromie@...il.com>
To: jbaron@...hat.com
Cc: bvanassche@....org, joe@...ches.com, gregkh@...e.de,
linux-kernel@...r.kernel.org, gnb@...h.org
Subject: dynamic_debug: enabled vs FLAGS_PRINT, more filtering tricks.
On Mon, Jul 25, 2011 at 3:42 PM, Jim Cromie <jim.cromie@...il.com> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists