1PMDAMAIN(3) Library Functions Manual PMDAMAIN(3)
2
6 pmdaMain, pmdaGetContext, pmdaSetResultCallBack, pmdaSetCheckCallBack,
7 pmdaSetDoneCallBack, pmdaSetEndContextCallBack - generic PDU processing
8 for a PMDA
9
11 #include <pcp/pmapi.h>
12 #include <pcp/impl.h>
13 #include <pcp/pmda.h>
14 cc ... -lpcp_pmda -lpcp
16 void pmdaMain(pmdaInterface *dispatch);
18 void pmdaSetCheckCallBack(pmdaInterface *dispatch,
19 pmdaCheckCallBack callback);
20 void pmdaSetDoneCallBack(pmdaInterface *dispatch,
21 pmdaDoneCallBack callback);
22 void pmdaSetResultCallBack(pmdaInterface *dispatch,
23 pmdaResultCallBack callback);
24 void pmdaSetEndContextCallBack(pmdaInterface *dispatch,
25 pmdaEndContextCallBack callback);
26 int pmdaGetContext(void);
27
30 For Performance Metric Domain Agents (PMDA(3)) using the binary PDU
31 protocols to communicate with pmcd(1), the routine pmdaMain provides a
32 generic implementation of the PDU-driven main loop.
33 dispatch describes how to process each incoming PDU. It is a vector of
35 function pointers, one per request PDU type, as used in the DSO inter‐
36 face for a PMDA, namely:
37 /*
39 * Interface Definitions for PMDA Methods
40 */
41 typedef struct {
42 int domain; /* set/return performance metrics domain id here */
43 struct {
44 unsigned int pmda_interface: 8; /* PMDA DSO interface version */
45 unsigned int pmapi_version : 8; /* PMAPI version */
46 unsigned int flags : 16; /* optional feature flags */
47 } comm; /* set/return communication and version info */
48 int status; /* return initialization status here */
49 union {
51 struct { /* PMDA_INTERFACE_2 or _3 */
52 pmdaExt *ext;
53 int (*profile)(__pmProfile *, pmdaExt *);
54 int (*fetch)(int, pmID *, pmResult **, pmdaExt *);
55 int (*desc)(pmID, pmDesc *, pmdaExt *);
56 int (*instance)(pmInDom, int, char *, __pmInResult **, pmdaExt *);
57 int (*text)(int, int, char **, pmdaExt *);
58 int (*store)(pmResult *, pmdaExt *);
59 } two, three;
60 struct { /* PMDA_INTERFACE_4 or _5 */
62 pmdaExt *ext;
63 int (*profile)(__pmProfile *, pmdaExt *);
64 int (*fetch)(int, pmID *, pmResult **, pmdaExt *);
65 int (*desc)(pmID, pmDesc *, pmdaExt *);
66 int (*instance)(pmInDom, int, char *, __pmInResult **, pmdaExt *);
67 int (*text)(int, int, char **, pmdaExt *);
68 int (*store)(pmResult *, pmdaExt *);
69 int (*pmid)(char *, pmID *, pmdaExt *);
70 int (*name)(pmID, char ***, pmdaExt *);
71 int (*children)(char *, int, char ***, int **, pmdaExt *);
72 } four, five;
73 struct { /* PMDA_INTERFACE_6 */
75 pmdaExt *ext;
76 int (*profile)(__pmProfile *, pmdaExt *);
77 int (*fetch)(int, pmID *, pmResult **, pmdaExt *);
78 int (*desc)(pmID, pmDesc *, pmdaExt *);
79 int (*instance)(pmInDom, int, char *, __pmInResult **, pmdaExt *);
80 int (*text)(int, int, char **, pmdaExt *);
81 int (*store)(pmResult *, pmdaExt *);
82 int (*pmid)(char *, pmID *, pmdaExt *);
83 int (*name)(pmID, char ***, pmdaExt *);
84 int (*children)(char *, int, char ***, int **, pmdaExt *);
85 int (*attribute)(int, int, const char *, int, pmdaExt *);
86 } six;
87 } version;
88 } pmdaInterface;
90 This structure has been extended to incorporate the multiple interface
92 versions that have evolved over time. For pmdaMain, dispatch->domain
93 and dispatch->status are ignored. The comm.pmda_interface field is
94 used to determine the interface used by the PMDA. Setting this field
95 to PMDA_INTERFACE_2 or PMDA_INTERFACE_3 will force pmdaMain to use the
96 callbacks in the version.two or version.three structure. A setting of
97 PMDA_INTERFACE_4 or PMDA_INTERFACE_5 will force pmdaMain to use the
98 callbacks in the version.four or version.five structure, and similarly
99 a PMDA_INTERFACE_6 setting forces pmdaMain to use the callbacks in the
100 version.six structure. Any other value will result in an error and
101 termination of pmdaMain.
102 Note that the use of dispatch as the interface between the pmcd(1) and
104 the methods of the PMDA allows each PMDA to be implemented as though it
105 were a DSO, with pmdaMain providing a convenient wrapper that may be
106 used to convert from the DSO interface to the binary PDU (daemon PMDA)
107 interface.
108 pmdaMain executes as a continuous loop, returning only when an end of
110 file is encountered on the PDU input file descriptor.
111
113 In addition to the individual PDU processing callbacks - pmdaPro‐
114 file(3), pmdaFetch(3), pmdaDesc(3), pmdaInstance(3), pmdaText(3), pmda‐
115 Store(3), pmdaPMID(3), pmdaName(3), pmdaChildren(3), and pmdaAt‐
116 tribute(3) there are other callbacks that can affect or inform all PDU
117 processing within a PMDA, namely check, done and end. These callbacks
118 should be set with pmdaSetCheckCallBack, pmdaSetDoneCallBack and pm‐
119 daSetEndContextCallBack.
120 If not null, check is called after each PDU is received (but before it
122 was processed), and done is called after each PDU is sent. If check
123 returns a value less than zero (typically PM_ERR_AGAIN), the PDU pro‐
124 cessing is skipped and in most cases the function value is returned as
125 an error PDU to pmcd(1) - this may be used for PMDAs that require some
126 sort of deferred connection or reconnect protocols for the underlying
127 sources of performance metrics, e.g. a DBMS. The error indication from
128 check is not passed back to pmcd(1) in the cases where no acknowledg‐
129 ment is expected, e.g. for a PDU_PROFILE.
130 The end callback allows a PMDA to keep track of state for individual
132 clients that are requesting it to perform actions (PDU processing).
133 Using pmdaGetContext a PMDA can determine, at any point, an integer
134 identifier that uniquely identifies the client tools at the remote end
135 of PMCD (for local context modes, this identifier is always zero).
136 This becomes very important for handling event metrics, where each
137 event must be propogated once only to each interested client. It also
138 underlies the mechanism whereby connection information is passed to the
139 PMDA, such as the the credentials (user and group identifiers) for the
140 client tool.
141 One final callback mechanism is provided for handling the pmResult
143 built for a PDU_RESULT in response to a PDU_FETCH request. By default,
144 pmdaMain will free the pmResult once the result has been sent to the
145 pmcd(1). For some PMDAs this is inappropriate, e.g. the pmResult is
146 statically allocated, or contains a hybrid of pinned PDU buffer infor‐
147 mation and dynamically allocated information. pmdaSetResultCallback
148 may be used to define an alternative callback from pmdaMain.
149
151 These messages may be appended to the PMDA's log file:
152 PMDA interface version interface not supported
154 The interface version is not supported by pm‐
155 daMain.
156 Unrecognized pdu type The PMDA received a PDU from pmcd that it does
158 not recognize. This may indicate that the pmcd
159 process is using a more advanced interface
160 than pmdaMain.
161 If the PMAPI(3) debug control variable (pmdebug) has the
163 DBG_TRACE_LIBPMDA flag set then each PDU that is received is reported
164 in the PMDA's log file.
165
167 pmcd(1), PMAPI(3), PMDA(3), pmdaProfile(3), pmdaFetch(3), pmdaDesc(3),
168 pmdaInstance(3), pmdaText(3), pmdaStore(3), pmdaPMID(3), pmdaName(3),
169 pmdaChildren(3), and pmdaAttribute(3).
170Performance Co-Pilot PCP PMDAMAIN(3)