Benjamin Allan

> How do we feel about adding a log-level option to the load command? That way we could get what plugin writers want/need and not have the possibility of waif...

@morrone "(pending registration)" means no plugin or framework has yet called register(context_name, context_description). I have provided usage examples above where the configurer of ldmsd would want to set the log...

There is a much more complicated implementation I could propose for a separate "preregistration" list. Such a list would collect all the log_level settings for names that cannot be permanently...

@morrone On the topic of "declarative" or not, a very common debugging log scenario is something like: ``` log_level name=sampler.foo level=debug load name=foo config name=foo log_level name=sampler.foo level=WARNING ``` where...

Even if we mix in log_level with load, that doesn't fix the problem that the current implementation for wildcard log name matching only applies to logs that are already registered....

@nichamon That is partially correct. In addition to the not loading example you correctly extracted, there is information I want logged at successful load time rather than waiting for config()...

> > @nichamon That is partially correct. In addition to the not loading example you correctly extracted, there is information I want logged at successful load time rather than waiting...

@tom95858 a substantial list of samplers (tx2mon, the various permutations on samplers of IB, omnipath, infiniband, slingshot, and lustre) would be improved by putting appropriate diagnostics in the load() implementation...

@nichamon, you mentioned: > Another crucial point is that LDMSD plugins **cannot** arbitrarily name their log subsystems. A plugin's log subsystem must align with `.`, where `` corresponds to the...

Given the changes in adjacent parts of the code, I will need to redo from scratch enabling multiple listeners from the command line.