[Openais] [patch] improved logging and tracing support

Steven Dake sdake at redhat.com
Wed Apr 5 00:12:06 PDT 2006


Hans

This patch looks good to me.

Unfortunately it collides with the recent 1170 defect fix.  I am
planning to commit the 1170 fix first since a) 1170 is complicated and
b) since I think porting your patch into trunk +1170 would be easier
then trunk + your patch and then porting 1170 on top of that c) it was
submitted first in final format.  I really want to avoid any errors of
these two merges for the 1170 patch.

Would you mind producing a patch against trunk + 1170?  Once that is
complete you should be able to merge with your write access to the repo
after I merge 1170 tomorrow.

Regards
-ateve

On Tue, 2006-04-04 at 14:16 +0200, Hans Feldt wrote:
> Here's a new version of the patch. Changes:
> - file & line support in totem
> - file & line configurable per service
> - file & line _not_ configurable in openais.conf (wait for new config)
> - AMF printfs converted to dprints and somewhat enhanced
> - log_init called in each service
> 
> Note that AMF logging and tracing will be overlooked more careful later 
> on. See amf.c amf_exec_init_fn() for an example how to enable tracing in 
> a service.
> 
> Note that with this patch, AMF will be silent after startup. To enable 
> healthcheck tracing do:
> 
> $ make CPPFLAGS=-DAMFDEBUG
> 
> To enable file & line for totem do:
> 
> $ make CPPFLAGS=-DTOTEM_DEBUG
> 
> Regards,
> Hans
> 
> Steven Dake wrote:
> > On Fri, 2006-03-31 at 09:12 +0200, Hans Feldt wrote:
> > 
> >>Steven Dake wrote:
> >>
> >>>Hans
> >>>I really like this !
> >>>Great patch!
> >>
> >>Thanks.
> >>
> >>
> >>>We don't have to do this for this patch, but eventually it would make
> >>>sense for the user to be able to select the log 20bit bitmask for each
> >>>of the services.
> >>>
> >>>It would be nice to be able to set whether line numbers are printed per
> >>>log service.
> >>
> >>I could do that.
> >>
> >>
> >>>The patch has this weird code which makes no sense:
> >>>
> >>>+       (void) log_service; // compiler warning
> >>>
> >>>is this necessary for some reason?
> >>
> >>print.h hides the log_service variable for "normal" users. For others 
> >>(e.g. mainconfig.c) that include print.h both does not use any of the 
> >>macros/functions in it I get a compiler warning, "unused variable".
> >>
> >>I found a GCC specific way to suppress the warning:
> >>
> >>static int log_service __attribute__((unused));
> >>
> > 
> > 
> > I see.  A simple description in comments about the funky looking code
> > might be a good solution to the question.
> > 
> > 
> >>>In which way must the totem code change for line numbers to be printed
> >>>out of the logger?  If you make changes to the interface to store
> >>>information about the log service such as whether it should print
> >>>loglines and which tag levels it should print, that should be
> >>>sufficient.
> >>
> >>My first idea:
> >>- introduce a macro in e.g. totemnet.c:
> >>
> >>#define totemnet_printf(level, format, args...) \
> >>     instance->totemnet_log_printf (__FILE__, __LINE__, level, format, 
> >>##args)
> >>
> >>- change all instance->totemnet_log_printf into totemnet_printf
> >>
> >>- pass another function when initialising totem.
> >>
> >>Good enough? What other environment is this code used in?
> >>
> > 
> > 
> > This works for me.  I'm not sure that totemnet_pg is used at all in
> > other applications, although it is possible.
> > 
> > Another option is to pass to the initialize function at the top level
> > whether the file and line number should be logged by the logger.
> > 
> > Regards
> > -steve
> > 
> > 
> >>Regards,
> >>Hans
> >>
> >>
> >>>Regards
> >>>-steve
> >>>
> >>>On Thu, 2006-03-30 at 10:02 +0200, Hans Feldt wrote:
> >>>
> >>>
> >>>>This patch is not complete but contains the central changes to print.? 
> >>>>and some example setup and tracing in amf.c
> >>>>
> >>>>Summary:
> >>>>==========
> >>>>- Removed service knowledge from print.*
> >>>>
> >>>>- Loggers/tracers "install" themselves with a service name using a new 
> >>>>function
> >>>>
> >>>>- log_printf() works as before
> >>>>
> >>>>- Possible to select file and line to be prepended to each line. Use 
> >>>>fileline=on in openais.conf, the logs can then be used to step through 
> >>>>with e.g. emacs using a buffer with compilation-mode
> >>>>
> >>>>- file/line not possible for totem code, needs interface changes
> >>>>
> >>>>- usecs added to time
> >>>>
> >>>>- trace tags can be used to trace independent flows (e.g. use cases)
> >>>>
> >>>>- trace tags: ENTER, LEAVE, TRACE1, TRACE2, TRACE3, ...
> >>>>
> >>>>- the trace service puts no meaning in tags, it is upto the designer
> >>>>
> >>>>- level and tags settable per logger
> >>>>
> >>>>Example:
> >>>>========
> >>>>
> >>>>
> >>>>>amf.c:2980 Mar 30  8:50:59.509542 [AMF  ] [DEBUG ] >message_handler_req_lib_amf_response
> >>>>>amf.c:2991 Mar 30  8:50:59.509576 [AMF  ] [DEBUG ] handling response connection interface 1
> >>>>>amf.c:3057 Mar 30  8:50:59.509600 [AMF  ] [DEBUG ] <message_handler_req_lib_amf_response
> >>>>>amf.c:2257 Mar 30  8:51:04.476808 [AMF  ] [DEBUG ] >healthcheck_activate
> >>>>>amf.c:2268 Mar 30  8:51:04.476841 [AMF  ] [DEBUG ] sending healthcheck to component comp_a_in_su_1
> >>>>>amf.c:2297 Mar 30  8:51:04.476870 [AMF  ] [DEBUG ] <healthcheck_activate
> >>>>
> >>>>Missing:
> >>>>========
> >>>>- external control over logging/tracing, I think support is needed in 
> >>>>the configuration file (to be able to trace startup) as well as some CLI 
> >>>>program that talks IPC with aisexec (to be able to change in runtime/field).
> >>>>
> >>>>
> >>>>Open issues:
> >>>>=============
> >>>>The log_printf2 don't seem to get inlined no matter what I do, any 
> >>>>hints? I tried a non-debug compile with no luck.
> >>>>
> >>>>
> >>>>What do you think, should I go ahead and create a complete patch?
> >>>>
> >>>>Regards,
> >>>>Hans
> >>>>
> >>>>_______________________________________________
> >>>>Openais mailing list
> >>>>Openais at lists.osdl.org
> >>>>https://lists.osdl.org/mailman/listinfo/openais
> >>>
> >>>
> >>>
> > 
> > 
> 




More information about the Openais mailing list