pcp
[Top] [All Lists]

pcp updates: scratch an itch

To: pcp@xxxxxxxxxxx
Subject: pcp updates: scratch an itch
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 7 Oct 2015 12:48:58 +1100
Delivered-to: pcp@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
Changes committed to git://git.pcp.io/kenj/pcp master

Ken McDonell (2):
      qa/972: (new) test $PCP_DEBUG
      libpcp: add $PCP_DEBUG to initialize pmDebug

 man/man1/pcpintro.1   |   10 ++
 man/man1/pmdbg.1      |   12 ++
 qa/792                |   53 +++++++++++
 qa/792.out            |  240 ++++++++++++++++++++++++++++++++++++++++++++++++++
 qa/group              |    1 
 src/libpcp/src/lock.c |   31 ++++++
 6 files changed, 346 insertions(+), 1 deletion(-)

Details ...

commit 8ded815b4497caffafd584dfae1066f901f66b47
Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date:   Wed Oct 7 12:42:12 2015 +1100

    libpcp: add $PCP_DEBUG to initialize pmDebug
    
    When debugging pcp-atop it became clear the that classical -D N way
    of setting PCP debug flags won't work for (an increasing set of?)
    applications that have alrady laid claim to a -D flag.
    
    So this commit provides an environment-based mechanism to initialize
    pmDebug from $PCP_DEBUG if set.
    
    Since all applications of interest use libpcp, and every application
    using libpcp ends up calling __pmInitLocks() early on, and that
    code has one-trip logic, then this is the right place to check the
    environment and update pmDebug if needed (note update, not set pmDebug,
    because the -D option processing might already have been done, so
    the value from $PCP_DEBUG is bitwise OR'd in).

commit 4f87342166c45f750a308ec509f0647b6b00856a
Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date:   Wed Oct 7 12:41:09 2015 +1100

    qa/972: (new) test $PCP_DEBUG

<Prev in Thread] Current Thread [Next in Thread>
  • pcp updates: scratch an itch, Ken McDonell <=