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; I don't usually comment on this kind of stuff, because I don't know that much about it. Nevertheless, at the risk of exposing my naivete, here's what I know and think: 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). 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. 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... 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. 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. Thanks, Matt ------------------------------------------------------------------------------ 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
