On Wed, 2013-02-27 at 02:07 +0100, Michael Haberler wrote: > 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 > My KISS mind seems to think that something like: /var/log/emc | /var/log/linuxcnc would be just fine. :-)
Dave > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
