Am 26.02.2013 um 16:23 schrieb Sebastian Kuzminsky: > I think we should use syslog(3), possibly with a thin wrapper around it.
Well having *all* error/notice etc messages go to syslog is part of the plan. That we dont have right now, I probably should have emphasized that. And syslog priority/facility filtering could come in handy. Using rfc5424 is probably a good idea as far as the encoding goes; not sure about the transport, see below >> 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. well yes, but how does an application which desires to display log messages in, say, a log window, get at them? You tail -f /var/log/something, I do, users cant be expected to. >> - 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. setting/showing the level does not imply 'logging in HAL' in some way - halcmd just happens to be the place where you try things out and having to use some arcane Unix command to get at *all* the error messages is pretty awkward, even for me just try to work out a halcmd file with a sim build and without a log window to see why the current halcmd behavior would benefit from improvement >> 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. Good question. Yes I think so, for instance the 'Unexpected realtime delay' message seems to travel that path; it is an RTAPI error message generated in motion which is treated specially. >> 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. Yes - the reason why they exist is to get rid of several special-purpose solutions, and the byzantine error reporting is one of them. > 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. It's about getting rid of some, not inventing new ones.. all messages should wind up in syslog anyway, and currently some do, some dont - so that is a goal Where our views differ - You seem to see error/debug/informational/warning etc messages as something which should exclusively go to syslog and hence to a file, or a console - that is fine in a development-only/headless setting I see them as normal application messages which should _also_ got to syslog, but there needs to be a mechanism how say a GUI hooks into messages, and reconfiguring the syslog setup to do that would be a rather awkward, given that an application-level messaging mechanism must exist anyway, whether that is NML or something else; in fact it would be yet another sidechannel to start with if used for application-level reporting, and those we have really enough of Note that the current stunt between motion and usrmotif is exactly what I propose to generalize - it transports an error message outside the current RT component logging mechanism (printk) because that was obviously considered inadaequate for a GUI application. I think that decision was the right one in principle, it just lacks generality - Michael ------------------------------------------------------------------------------ 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
