So I've been staring at a wall for a few hours and not only have I seen
fascinating patterns of false color after I look away from it for a few
seconds, but I've also got an idea of how to make this work. For those of
you just joining us, I'm talking about moving "METRICNAME_func" out of the
individual machine.c files and leaving just the bare-bones data-collection
logic in machine.c.
Kinda simple, really.
We move metric_init and METRICNAME_func into a "metric.c" or
"metric_func.c" file and rework the functions in machine.c as simple
polling functions. Pass it a g_val_t and it populates the appropriate type
and returns a value according to whether the poll succeeded, failed, or is
unsupported on this platform. As long as every poll function can handle
these three outcomes gracefully there should be no problems.
Well, assuming we document the expectations of each metric function when it
uses a poll function. In other words, "get_cpu_percentages expects to get
a nonzero counter of type uint32 containing the number of jiffies spent by
all CPUs when it polls each CPU mode - user, system, idle and nice."
Hopefully a would-be porter would only have to read two files to get an
idea of what is required - a skeletal machine.c file and this metric.c file.
Also for consideration:
- Special behavior for G_METRIC_NOT_IMPLEMENTED? Sure, the metric will
return zero, but perhaps it should return something that makes it to the
XML display that gmetad can see. Maybe SLOPE="ASYMPTOTE"? :P
- In some cases this will reduce but not totally eliminate crunching
numbers in the data collection functions. For example, on Tru64 I can only
get memory usage in pages. I have to multiply each page group by the page
size, determine the type of usage it's using, and then add it to the
appropriate counter before I can return the data in a format the calling
function expects (i.e., kilobytes :) ).
- I wasn't really staring at the wall.
So ... any thoughts?
