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.
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 What stares at me is (current RTAI code, and 'sim'): RT build: - RTAPI error messages from RT modules go through rt_printk to the kernel log to be viewed with 'dmesg' - 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. - 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. 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. 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. Maybe I am a hopeless romantic believing 'doing it right once' is the way to go to clean up this horrible mess. 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). - Michael While switching to syslog _formatting_ (as opposed to transport) of messages might be considerable work for no immediate upside, I note it is even an IETF standard these days: http://tools.ietf.org/html/rfc5424 , and some experience can be learned from it. ------------------------------------------------------------------------------ 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
