-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/11/2014 01:54 PM, Jan Synacek wrote:
I like this idea. See my notes embedded below.
I've been trying trying to implement the SELinux provider for a
while now. It is written in C and it uses the new job manager. So
far, I've only had to implement jobs in storage, which is python,
and that was relatively easy compared to all the detail that has to
be taken care of in C.
This complexity, and the fact that debugging it is pretty hard, led
me to an idea...
I suggest that all the providers (I'm now mainly concerned about
openlmi-providers) have a common, unified tracing facility. We
should be able to turn it on as the lowest logging level and it
should trace entrance/exit of all functions. This would make
debugging and pinpointing failures much easier.
#define lmi_trace_in lmi_debug("==> %s", __PRETTY_FUNCTION__);
#define lmi_trace_out lmi_debug("<== %s", __PRETTY_FUNCTION__);
#define lmi_trace_out_rc(rc) lmi_debug("<== %s (rc=%d)",
__PRETTY_FUNCTION__, rc);
Plain RC is a little bit misleading when used in
functions returning
anything else than CMStatus. Boolean return value is such a case (1
usually means success and 0 failure). Quite the contrary to CMStatus.rc.
Perhaps above tracing functions could be extended with:
#define lmi_trace_out_bool(val) lmi_debug("<== %s (res=%s)", \
__PRETTY_FUNCTION__, val ? "true" : "false");
#define lmi_trace_out_status(status) lmi_debug("<== %s (rc=%d (%s),
msg=%s)", \
__PRETTY_FUNCTION__, status.rc, _rc_names[status.rc], status.msg);
I also find very useful having information about executing thread
embedded in tracing message. Dbus providers tend to be multithreaded and
sometimes it is hard to deduce the flow of execution when outputs of
multiple threads are mixed together.
Every function would look like:
void function() { lmi_trace_in
stuff();
lmi_trace_out /* or lmi_trace_out_rc(rc) where relevant */ }
Note that "lmi_debug" could be replaced with something like
"lmi_trace", which would be defined via CMPI bindings to be even
lower level than "lmi_debug".
I vote for lmi_trace() method. Tracing
methods shouldn't be mixed with
debug ones. Let's have another logging levels for them. We could also
reuse tracing levels from our python providers:
INFO > DEBUG > TRACE_WARNING > TRACE_INFO > TRACE_VERBOSE
Commonly used levels (ERROR, WARNING, INFO, DEBUG) are handled with
CMLogMessage(), while the tracing ones with CMTraceMessage(). Broker
then allows for fine-grained logging setup to filter out uninteresting
messages.
I'm in favor of following our python logging pattern. We could use the
same configuration templates for our C and python providers and thus
avoid a risk of confusing our users.
Suggestions and constructive criticism welcome.
Michal M.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iQEcBAEBAgAGBQJTv+CmAAoJEPezUylxRFUD4woH/iEQIXkhZywb0Pf+fs49Vc9l
UqY8kxtU+CGQHzz/LdnRPlVBmdAP6IAYtT70JL3R6IN/fRC2XVsEHCS5cscaBW9Q
O/6XHA2s6i195dqJlPe74LIRNGXDFPJCaKupNbXedWge92sN7yw2buaiPw//vhLt
MSaRecHySm5/I7MbgeeUyebqfUKygEpxpzWTIP5tXPIxD1Tfp4YeKpSMnbGMm1mu
RTtT8o2kncwiPj2vOX/W/gA+CDdGlHWD8mUHm6PLBkYj7engsuOu88fZ8+pOaIKv
a97L+16pvmcpn65XsIqop+LVN1TPGDtZYKEEAW1JiZAyxn1cqK4fBZIKdOgieW0=
=zD0p
-----END PGP SIGNATURE-----