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 ABC?
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- debug" is not configured. I also do not want the error to show up all the time,
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 there were any guidelines about its use? Or if I should be thinking about some
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)?

--
Jeff Squyres
Cisco Systems

Reply via email to