Clarify rig_debug() explanation.

Hamlib-1.2.15
Nate Bargmann 2011-12-03 11:31:40 -06:00
rodzic 3dedd4404f
commit 929b0ac49e
1 zmienionych plików z 13 dodań i 9 usunięć

Wyświetl plik

@ -588,26 +588,28 @@ via the Hamlib API. From an application's perspective, setting a specific
level includes all messages at that level and all at any lower level. level includes all messages at that level and all at any lower level.
In the library, passing RIG_DEBUG_ERR to rig_debug() limits display of that In the library, passing RIG_DEBUG_ERR to rig_debug() limits display of that
message to a level setting of ERR or BUG. Use of a given level can show the message to a level setting of ERR or any higher level. In this case if the
value of a critical variable without the need of a TRACE level message which application sets the message level to RIG_DEBUG_INFO, the message will not
can get lost in the stream of output produced by low-level Hamlib functions. be seen. Use of a given level can show the value of a critical variable
without the need of a TRACE level message where it can get lost in the
stream of output produced by low-level Hamlib functions.
Here are my (N0NB's) suggested use of rig_debug() levels in backends. Here are my (N0NB's) suggested use of rig_debug() levels in backends.
* Many backend functions should have an initial call to rig_debug() as follows: * Many backend functions should have an initial call to rig_debug() as follows:
rig_debug(RIG_DEBUG_VERBOSE, "%s called\n", __func__); rig_debug(RIG_DEBUG_VERBOSE, "%s() entered\n", __func__);
The use of RIG_DEBUG_VERBOSE allows tracking the chain of function calls The use of RIG_DEBUG_VERBOSE allows tracking the chain of function calls
through the backend while still keeping rigctl's output mostly through the backend while still keeping rigctl's output mostly
uncluttered by use of the -vvvv switch. uncluttered by use of the -vvvv switch.
* Developers will want to call rig_debug() to display values of critical * Developers will want to call rig_debug() to display values of critical
variable(s) in a backend function. For this RIG_DEBUG_VERBOSE should be variable(s) in a backend function. For this RIG_DEBUG_VERBOSE
a good choice as the output won't be lost in the stream of RIG_DEBUG_TRACE (rigctl -vvvv) should be a good choice as the output won't be lost in the
level output by various low-level Hamlib functions (rigctl -vvvv). It will stream of RIG_DEBUG_TRACE (rigctl -vvvvv) level output by various
also match the display of the values of critical variable(s) with the low-level Hamlib functions. It will also match the display of the values
function calls as above. of critical variable(s) with the function calls as above.
* Use RIG_DEBUG_TRACE when it makes sense to see the variable(s) in the * Use RIG_DEBUG_TRACE when it makes sense to see the variable(s) in the
context of a lot of low-level debugging output (rigctl -vvvvv). context of a lot of low-level debugging output (rigctl -vvvvv).
@ -623,6 +625,8 @@ If an application sets the debugging level to RIG_DEBUG_NONE, then
rig_debug() functions will produce no output. Therefore rig_debug() cannot rig_debug() functions will produce no output. Therefore rig_debug() cannot
be counted on to output a message in all runtime cases. be counted on to output a message in all runtime cases.
The debugging levels may be an area for consideration in API_3.
8.3 Submitting patches 8.3 Submitting patches