PMDAGETOPTIONS(3)

💖 PMDAGETOPTIONS(3) — Library Functions Manual 💖

okay bestie, so this is a page from the Performance Co-Pilot library functions manual, and it's literally all about pmdaGetOpt and pmdaGetOptions, the two little icons that go grab options off your argument list and handle all the generic PMDA stuff for you ✨

---

✨ NAME ✨

pmdaGetOpt, pmdaGetOptions — get options from arguments, parsing generic PMDA options 🎀

---

🌸 C SYNOPSIS 🌸

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

int pmdaGetOptions(int argc, char *const *argv, pmdaOptions *opts,
                   pmdaInterface *dispatch);
int pmdaGetOpt(int argc, char *const *argv, const char *optstring,
               pmdaInterface *dispatch, int *err);

cc ... -lpcp_pmda -lpcp

---

🦋 DESCRIPTION 🦋

so these two are basically wrappers for pmgetopt_r(3), no cap. the whole vibe is that certain options are assumed to have a predefined behavior, and that behavior initializes a bunch of fields in the pmdaInterface structure for you. main character energy fr fr 💅

• pmdaGetOptions — the ✨fancy✨ one: it lets you have both short and long options.
• pmdaGetOpt — the lowkey one: short form options only.

🌈 the options that BOTH of them will trap 🌈

okay these are the ones both pmdaGetOptions and pmdaGetOpt snatch up:

• -Ddebugspec — sets the PMAPI(3) debugging options to debugspec, exactly as described in PCPIntro(1). it's giving "controlling levels of trace output while debugging" 🐛
• -ddomain — sets the domain number of this agent.
• -hhelpfile — grabs the help text (peep pmdaText(3)) for the metrics from this file instead of from the path you specified with pmdaDSO(3) or pmdaDaemon(3).
• -iport — expects PMCD to connect on inet port (number or name).
• -6port — expects PMCD to connect on ipv6 port (number or name).
• -llogfile — redirects diagnostics and trace output to logfile.
• -p — expects PMCD to supply stdin/stdout pipe.
• -usocket — expects PMCD to connect on unix domain socket.

🎀 and the extra one that ONLY pmdaGetOptions captures 🎀

pmdaGetOptions will also capture this one, and store it inside the opts parameter:

• -Uusername — sets the user account name under which the PMDA should execute.

bestie, listen: only one of -i, -6, -p and -u may be specified. if none of these three options is given, a pipe (-p) is assumed. yes, the manpage says "these three" while listing four — iconic behavior, we don't question it 💀

when these options are encountered by pmdaGetOpt, the option gets processed and the next option is examined. so pmdaGetOpt will only return when an option that is not one of the ones listed above is found, or when the end of the list is reached. the returned value will be the argument, or EOF, respectively. 🫶

a PMDA can control which of these options the program will accept with either the opts or the optstring argument:

• to accept all the options, call pmdaGetOptions with the short_options field of the opts structure set to the PMDA_OPTIONS macro,
• or call pmdaGetOpt with the option string "D:d:h:i:l:pu:".

any PMDA specific options should be added to these strings in the style of getopt(3), and they'll be returned by both pmdaGetOptions and pmdaGetOpt if encountered. slay 💅

when a command line option usage error is detected in the pmdaGetOptions interface, the error field of the opts structure will contain a non-zero error count.

pmdaGetOpt takes a pointer to an int, err, which is used as an error count. this variable should be initialized to zero before pmdaGetOpt is first called, and tested when pmdaGetOpt returns EOF.

neither pmdaGetOptions nor pmdaGetOpt modify their argc or argv parameters. they would NEVER. hands off 🙈

the global variables used by the system getopt(3) interface may also be used by the caller of pmdaGetOpt within the argument parsing loop. 👑

on the other hand, the pmdaGetOptions interface does not utilize global variables at all — neither reading nor modifying them. instead, these variables can be access via the opts fields of the same name. iykyk ✨

---

💀 CAVEAT 💀

the options -D, -d, -i, -l, -p and -u cannot be reused for other purposes by the PMDA, unless using the override method provided by the pmdaGetOptions interface, which operates in the same way as described for the pmGetOptions(3) interface used by PMAPI client tools. so don't try it bestie, that's a no 💅

the PMDA must be using PMDA_INTERFACE_2 or later, as specified in the call to pmdaDSO(3) or pmdaDaemon(3). periodt.

---

🔥 DIAGNOSTICS 🔥

both pmdaGetOptions and pmdaGetOpt will display the same error messages as getopt. matching energy, honestly 🌈

---

⭐ SEE ALSO ⭐

pmdbg(1), getopt(3), pmgetopt_r(3), pmGetOptions(3), PMAPI(3), PMDA(3), pmdaDaemon(3), pmdaDSO(3) and pmdaText(3).

---

and that's the whole page, bestie 🦋✨ this one came from Performance Co-Pilot (PCP) — it's the PMDAGETOPTIONS(3) page 💖 go forth and parse your options, you absolute legend 👑