ldms sampler logging needs per-sampler log levels

[morrone]

Apparently there is a need for having different logging levels enabled in different ldms sampler plugins at the same time.

One way to achieve this goal is to pass an opaque logging handle to the plugin at get_plugin() time. This handle would embed or reference the currently configured logging level for that particular plugin (reference is probably better so that ldmsd can change the logging level without the plugin needing to be involved). The sample plugins would simply call a standard logging function that is exported by the ldms library, that looks something like this:

  void ldmsd_sampler_log(ldms_log_handle_t handle, enum ldmsd_loglevel level, const char *fmt, ...);

[baallan]

It would be a relatively easy global change to the existing logging functions to do something like you suggest. It's generic to a logging context, and vaguely similar to log4j if we

sed -e 's/LDMSD_L/logctxt, LDMSD_L/g'

across all our code and then move the logging functions into a library.

In the case of plugins, the init and fini hooks would initialize a

static ldms_log_context_t logctxt = ldms_log_context_register("sampler.lustre_client");

This would be atomic enough to be retrofitted quickly on v4 before it is released. The tuning of log levels could be log4j-esque log_level= to set the global defaults as now. log_level=$contextname.[,name.] we could accept subsystem context name with * on dot qualified names: log_level=sampler..WARNING,store..DEBUG

For speed (no looking up context names) we could map ldms_log_context_t to an int index into a private array of level values in the logging library.

[baallan]

@morrone can we close this as being subsumed in change proposal 5?