On 02/26/2013 01:38 AM, Michael Haberler wrote: > I am looking into unified error message reporting in the HAL/RTAPI context. > The reason is: if LinuxCNC, or at least it's RT/HAL part, is ever to work in > a distributed fashion, error message reporting needs to be cleaned up, among > other issues.
Logging within the various parts of LinuxCNC is kind of chaotic and haphazard at the moment, and I would welcome a cleanup. > The goal is simple: No matter what RTOS or thread style is used, or which > element generates an error: > > - all messages shall be reported through a single channel, including its > reporting level, and preferrably its origin too > - setting a message reporting level shall apply to all elements in a uniform > way I think we should use syslog(3), possibly with a thin wrapper around it. The problems i run in to with the current logging system are more practical than architectural: * Different parts of linuxcnc log to different files and/or places. Some things log to the console, some to files. * Different parts of linuxcnc use different mechanisms (usually ini variables) to control their verbosity. * Some log files are removed on exit! > RT build: > - RTAPI error messages from RT modules go through rt_printk to the kernel log > to be viewed with 'dmesg' This is the standard log channel for kernel code. > - the message level for _RT modules_ is set by writing to /proc/rtapi/debug. > - the /proc/rtapi/debug mechanism does not apply to usermode components. The > message level setting in usermode components is per-process, not systemwide. This makes sense to me. > - If motion is used, RTAPI *error messages* (level=RTAPI_MSG_ERR) are > reported through a separate vehicle in motion (emcmotError) to task or > whoever talks to motion > - this destination is disjoint from lower level (level<RTAPI_MSG_ERR) RTAPI > messages, which still got to the kernel log (I think - the logic is, well, > involved) > - there is some super-clever, super-comment-free code to funnel printf > arguments out of the kernel, to deal with the fact that printf support for > floats/doubles in-kernel is severely limited (motion/dbuf*). > - halcmd has no way of setting or reporting the current message level. This last doesnt bother me. Logging level is a fairly meta thing, and i dont mind if it's disjoint from HAL. > sim build: > - there is no /proc/rtapi/debug since sim builds dont sport kernel modules > and hence no procfs/sysfs entries > - the program which runs 'sim RT modules', rtapi_app, currently has no way of > setting the RTAPI message level for the simulated RT components. > - hence, with userland setting the message level in a usermode component does > not apply to any 'simulated RT components' either > - if you want more detailed (level<RTAPI_MSG_ERR) RTAPI error messages from > an RT component with the userland thread styles, the current method is to add > a 'rtapi_set_msg_level()' to rtapi_app_main of the component in question, and > recompile (I would love to be corrected on this wart.) > - this 'sim build' situation applies to all userland thread styles (xenomai, > RT-PREEMPT, Posix). RT components happily print to the 'console' (wherever > that output goes), since it's all usermode now. Standard out and standard error of all linuxcnc processes is captured by the linuxcnc starter script and written to a log file in tmp. The logfile is given a random name, and removed when linuxcnc exits, both these behaviors make it harder than it should be to inspect them. > It might well be that I overlooked or misinterpreted some of the hoops error > messages travel - clarifications welcome. > > I would also appreciate an explanation why motion error messages are so > totally different that they just have to have their own special-purpose > vehicle - I dont get it. IMO sending an error message is a UI affair and has > no semantic significance, and it is disjoint from communicating error status, > for which motion has its own mechanism. Do motion errors go to the LinuxCNC GUI, for display to the operator? I know some Task/Interp messages do. > Maybe I am a hopeless romantic believing 'doing it right once' is the way to > go to clean up this horrible mess. "Doing it right" is easier said than done, and reasonable people may differ in their definition of "right". ;-) But the discussion is welcome, and I agree LinuxCNC logging could use a cleanup. > Barring better suggestions, the way I will go about it is: > > - RTAPI will get a mechanism to set and query a message level setting which > is accessible to all components, regardless of RTOS and thread style. > - _all_ RTAPI error message will be handled according to this setting. > - halcmd will learn a command to set and report said message level, and that > will apply universally too. > - all RT/HAL originated error messages will eventually travel through a > single new mechanism, HAL queues, which are named, lock-free pipes (this > works but isnt merged yet). The latter is part of a quest to weed out and > simplify at least 6 different special-purpose messaging mechanisms currently > in use to communicate non-HAL-pin values between RT and non-RT space. > - any part, local or remote, will be able to 'listen' to error messages, as > they will be published through a publish/subscribe service. Syslog might be > an obvious recipient, as would be user interfaces. > - RTAPI will get a standard way of tagging a message by its origin such that > it can be processed according to origin (eg 'I want all motion-originated > messages' - basically what syslog(3) supports since a mere 30 years). The way > this could be done is to introduce an origin-tagged variant of > rtapi_print_msg(), and have current rtapi_print_msg() calls sport a default > origin tag for a start, enabling piecemeal adaptation (and maybe > semi-automatic re-editing). I think it's valuable to have all parts of linuxcnc put their log messages in predictable places, and have a simple mechanism to control who logs how much. I don't think a pub/sub system is needed or wanted for logs. I don't think log messages should go through HAL, but maybe I just dont know enough about your HAL pipes. I'm used to the originator of a log message tagging their messages by prepending "name: ", then grepping them out of the syslog. I'm happy with this. I'm leery of inventing yet another custom logging system. It would have to be a significant improvement over just writing to a file or to the syslog for me to be excited about it. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
