On Jul 6, 2007, at 5:20 PM, Don Kerr wrote:
> Are there any guidelines about the use of opal_output_verbose?
Not so much.
> - Are there hidden meanings for a given verbose level? e.g. 0
> reserved for PML, or 50-100 for BTL and so on
Nope. The output was designed to use the values with >= kinds of
checking; i.e., the higher the verbose value the user gives, the more
output they see. I.e., the values are not used in a "bit flag" sense
(i.e., each bit enables/disables a specific set of output).
> - Maybe the base component output_id is ok to use in situation
> XYZ but a component specific output_id should be used in situation
> Or should never be used for component specific output?
I've typically used the base component output_id whenever possible.
I usually started off having an output ID for a specific component,
but usually that was for debugging (and therefore having oodles and
oodles of output). By the time I was done, I usually had only a few
output statements and therefore used the base ID.
I guess my suggestion would be: if you're going to have a LOT of
output, then make it a component-specific ID. If it's a "reasonable"
amount, then just use the base ID. Definitions of those terms are
subjective and intentionally fuzzy. :-)
> Why I ask. I want to report a warning to the user when "--enable-
> is not configured. I also do not want the error to show up all the
> only when for example --mca btl_base_debug is set to some value. I am
> thinking I will just use opal_output_verbose but wanted to see if
> were any guidelines about its use? Or if I should be thinking about
> other option all together.
You want a warning to show when:
1. the udapl btl is used
2. --enable-debug was not configured
3. the user specifies btl_*_verbose (or btl_*_debug) >= some_value
Is that right? If so, is the intent to warn that somen checks are
not being performed that one would otherwise assume are being
performed (because of #3)?