Matt, Am 26.02.2013 um 23:47 schrieb Matt Shaver:
> On Tue, 26 Feb 2013 21:19:53 +0100 > Michael Haberler <mai...@mah.priv.at> wrote: > >> I think we should have the option to log everything, and through a >> singel channel; > > 1. Originally, messages ended up in the kernel log because real time > components had no access to user space things like file I/O. They did > have access to the shared memory buffer, and could printk into the log > (IIRC). Well they dont do file I/O nowadays either; it's just that even for kernel thread styles like RTAI there is a mechanism in place which can be used to clean that up. > 2. Otherwise (in user space), communications was supposed to be via > the NML channels, of command, status, and error. This is analogous to > the Unix stdin, stdout, and stderr. Both of these systems have a > dedicated channel for error communications. That's fine in theory, unfortunately the scheme doesnt work satisfactorily across the the RT boundary, and likely not with some of the recent userland RT threadstyles either > 3. I thought, and this is where I may misunderstand a lot of things, > that there were discussions about using a messaging system like > 0MQ/crossroads.io/nano/??? to replace NML and be the "Grand Unified > Communications Mechanism". Or did I miss an important meeting... One could proceed with the current logging situation with NML or some other middleware; but changing the middleware doesnt clean up the existing logging act, so it is rather independent of that All the items I listed - except 4&5 in the last paragraph - on rtapi msglevel systemwide, one channel for all of the messages (not just motion) etc apply to the current scheme 1:1 > 4. If you're going to have a GUCM (see above), use it! If some errors > should go in the kernel log or a log file in the user's home directory, > (a) small program(s) can subscribe to the error socket and distribute > the messages as desired. Yes, I was addressing a unified transport to which other mechanisms, like syslog or program log windows can hook into. Whether you attach to an NML queue or a ZMQ socket is just a variation in detail, likely hidden in a library. The way how it is done in motion/RTAI with Jeff's dbuf code for kernel thread styles - is a good solution, it's just lacking a bit of generality so it applies to all components in a uniform way, and with a more general way of distributing error messages > 5. Does RTAI or Xenomai lessen or eliminate the restriction on real > time components ability to access user space? If so, then these > components can publish their error (and status) to the relevant GUCM > sockets/channels. If not, into the kernel log they go via printk. It's rather userland threads versus kernel threads than kernel X vs Y, and all the issues are already there with the differences between sim and RT behavior. Since I dont see RTAI being dropped any day soon both thread styles need to be supported in a coherent way, even if it is the only kernel RT thread system remaining. Once we reach a situation where UI and realtime environment can be separated and not everything needs to run on a single CPU, things become more pressing to make logging more network ready - the alternative being *two* windows with tail -f /var/log/somelog, one of them remote. - 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
