pmdamain(3) — Linux manual page

NAME | C SYNOPSIS | DESCRIPTION | CALLBACKS | DIAGNOSTICS | SEE ALSO | COLOPHON

PMDAMAIN(3)             Library Functions Manual             PMDAMAIN(3)

NAME         top

       pmdaMain, pmdaGetContext, pmdaSetResultCallBack,
       pmdaSetCheckCallBack, pmdaSetDoneCallBack,
       pmdaSetEndContextCallBack - generic PDU processing for a PMDA

C SYNOPSIS         top

       #include <pcp/pmapi.h>
       #include <pcp/pmda.h>

       cc ... -lpcp_pmda -lpcp

       void pmdaMain(pmdaInterface *dispatch);
       void pmdaSetCheckCallBack(pmdaInterface *dispatch,
               pmdaCheckCallBack callback);
       void pmdaSetDoneCallBack(pmdaInterface *dispatch,
               pmdaDoneCallBack callback);
       void pmdaSetResultCallBack(pmdaInterface *dispatch,
               pmdaResultCallBack callback);
       void pmdaSetEndContextCallBack(pmdaInterface *dispatch,
               pmdaEndContextCallBack callback);
       int pmdaGetContext(void);

DESCRIPTION         top

       For  Performance  Metric Domain Agents (PMDA(3)) using the binary
       PDU protocols to communicate with pmcd(1), the  routine  pmdaMain
       provides a generic implementation of the PDU-driven main loop.

       dispatch describes how to process each incoming PDU. It is a vec‐
       tor  of  function  pointers, one per request PDU type, as used in
       the DSO interface for a PMDA, namely:

       /*
        * Interface Definitions for PMDA Methods
        */
       typedef struct {
           int domain;         /* set/return performance metrics domain id here */
           struct {
               unsigned int    pmda_interface: 8; /* PMDA DSO interface version */
               unsigned int    pmapi_version : 8; /* PMAPI version */
               unsigned int    flags : 16;        /* optional feature flags */
           } comm;             /* set/return communication and version info */
           int status;         /* return initialization status here */

           union {
               struct {                              /* PMDA_INTERFACE_2 or _3 */
                   pmdaExt *ext;
                   int (*profile)(pmProfile *, pmdaExt *);
                   int (*fetch)(int, pmID *, pmResult **, pmdaExt *);
                   int (*desc)(pmID, pmDesc *, pmdaExt *);
                   int (*instance)(pmInDom, int, char *, pmInResult **, pmdaExt *);
                   int (*text)(int, int, char **, pmdaExt *);
                   int (*store)(pmResult *, pmdaExt *);
               } two, three;

               struct {                              /* PMDA_INTERFACE_4 or _5 */
                   pmdaExt *ext;
                   int     (*profile)(pmProfile *, pmdaExt *);
                   int     (*fetch)(int, pmID *, pmResult **, pmdaExt *);
                   int     (*desc)(pmID, pmDesc *, pmdaExt *);
                   int     (*instance)(pmInDom, int, char *, pmInResult **, pmdaExt *);
                   int     (*text)(int, int, char **, pmdaExt *);
                   int     (*store)(pmResult *, pmdaExt *);
                   int     (*pmid)(char *, pmID *, pmdaExt *);
                   int     (*name)(pmID, char ***, pmdaExt *);
                   int     (*children)(char *, int, char ***, int **, pmdaExt *);
               } four, five;

               struct {                              /* PMDA_INTERFACE_6 */
                   pmdaExt *ext;
                   int     (*profile)(pmProfile *, pmdaExt *);
                   int     (*fetch)(int, pmID *, pmResult **, pmdaExt *);
                   int     (*desc)(pmID, pmDesc *, pmdaExt *);
                   int     (*instance)(pmInDom, int, char *, pmInResult **, pmdaExt *);
                   int     (*text)(int, int, char **, pmdaExt *);
                   int     (*store)(pmResult *, pmdaExt *);
                   int     (*pmid)(char *, pmID *, pmdaExt *);
                   int     (*name)(pmID, char ***, pmdaExt *);
                   int     (*children)(char *, int, char ***, int **, pmdaExt *);
                   int     (*attribute)(int, int, const char *, int, pmdaExt *);
               } six;
           } version;

       } pmdaInterface;

       This structure has been extended to incorporate the multiple  in‐
       terface versions that have evolved over time.  For pmdaMain, dis‐
       patch->domain  and  dispatch->status  are  ignored.  The comm.pm‐
       da_interface field is used to determine the interface used by the
       PMDA.  Setting this field to PMDA_INTERFACE_2 or PMDA_INTERFACE_3
       will force pmdaMain to use the callbacks in  the  version.two  or
       version.three  structure.   A  setting of PMDA_INTERFACE_4 or PM‐
       DA_INTERFACE_5 will force pmdaMain to use the  callbacks  in  the
       version.four  or version.five structure, and similarly a PMDA_IN‐
       TERFACE_6 setting forces pmdaMain to use  the  callbacks  in  the
       version.six  structure.   Any other value will result in an error
       and termination of pmdaMain.

       Note that the use  of  dispatch  as  the  interface  between  the
       pmcd(1) and the methods of the PMDA allows each PMDA to be imple‐
       mented  as though it were a DSO, with pmdaMain providing a conve‐
       nient wrapper that may be used to convert from the DSO  interface
       to the binary PDU (daemon PMDA) interface.

       pmdaMain  executes  as  a continuous loop, returning only when an
       end of file is encountered on the PDU input file descriptor.

CALLBACKS         top

       In  addition  to  the  individual  PDU  processing  callbacks   -
       pmdaProfile(3),   pmdaFetch(3),   pmdaDesc(3),   pmdaInstance(3),
       pmdaText(3),     pmdaStore(3),     pmdaPMID(3),      pmdaName(3),
       pmdaChildren(3),  and  pmdaAttribute(3) there are other callbacks
       that can affect or inform all PDU processing within a PMDA, name‐
       ly check, done and end.  These callbacks should be set  with  pm‐
       daSetCheckCallBack,    pmdaSetDoneCallBack   and   pmdaSetEndCon‐
       textCallBack.

       If not null, check is called after each PDU is received (but  be‐
       fore  it  was  processed),  and  done is called after each PDU is
       sent.  If  check  returns  a  value  less  than  zero  (typically
       PM_ERR_AGAIN),  the  PDU  processing is skipped and in most cases
       the function value is returned as an error PDU to pmcd(1) -  this
       may  be used for PMDAs that require some sort of deferred connec‐
       tion or reconnect protocols for the underlying sources of perfor‐
       mance metrics, e.g. a DBMS.  The error indication from  check  is
       not  passed  back to pmcd(1) in the cases where no acknowledgment
       is expected, e.g. for a PDU_PROFILE.

       The end callback allows a PMDA to keep track of state  for  indi‐
       vidual  clients  that  are  requesting it to perform actions (PDU
       processing).  Using pmdaGetContext a PMDA can determine,  at  any
       point,  an integer identifier that uniquely identifies the client
       tools at the remote end of PMCD (for local  context  modes,  this
       identifier is always zero).  This becomes very important for han‐
       dling event metrics, where each event must be propagated once on‐
       ly  to  each  interested client.  It also underlies the mechanism
       whereby connection information is passed to the PMDA, such as the
       the credentials (user and group identifiers) for the client tool.

       One final callback mechanism is provided for handling  the  pmRe‐
       sult  built  for a PDU_RESULT in response to a PDU_FETCH request.
       By default, pmdaMain will free the pmResult once the  result  has
       been  sent to the pmcd(1).  For some PMDAs this is inappropriate,
       e.g. the pmResult is statically allocated, or contains  a  hybrid
       of pinned PDU buffer information and dynamically allocated infor‐
       mation.   pmdaSetResultCallBack may be used to define an alterna‐
       tive callback from pmdaMain.

DIAGNOSTICS         top

       These messages may be appended to the PMDA's log file:

       PMDA interface version interface not supported
              The interface version is not supported by pmdaMain.

       Unrecognized pdu type
              The PMDA received a PDU from pmcd that it does not recog‐
              nize. This may indicate that the pmcd process is using a
              more advanced interface than pmdaMain.

       If the PMAPI(3) debugging control options have the ``libpmda''
       option set then each PDU that is received is reported in the PM‐
       DA's log file.

SEE ALSO         top

       pmcd(1), PMAPI(3), PMDA(3), pmdaProfile(3), pmdaFetch(3),
       pmdaDesc(3), pmdaInstance(3), pmdaText(3), pmdaStore(3),
       pmdaPMID(3), pmdaName(3), pmdaChildren(3), and pmdaAttribute(3).

COLOPHON         top

       This page is part of the PCP (Performance Co-Pilot) project.  In‐
       formation about the project can be found at ⟨http://www.pcp.io/⟩.
       If you have a bug report for this manual page, send it to
       [email protected].  This page was obtained from the project's
       upstream Git repository
       ⟨https://github.com/performancecopilot/pcp.git⟩ on 2024-06-14.
       (At that time, the date of the most recent commit that was found
       in the repository was 2024-06-14.)  If you discover any rendering
       problems in this HTML version of the page, or you believe there
       is a better or more up-to-date source for the page, or you have
       corrections or improvements to the information in this COLOPHON
       (which is not part of the original manual page), send a mail to
       [email protected]

Performance Co-Pilot               PCP                       PMDAMAIN(3)

Pages that refer to this page: pmda(3)pmdaattribute(3)pmdachildren(3)pmdaeventclient(3)pmdaname(3)pmdapmid(3)