Chris Radek wrote:
> On Tue, Feb 26, 2013 at 05:09:42PM +0100, Michael Haberler wrote:
>
>> all messages should wind up in syslog anyway
>>
>
> I don't agree with this. We have an odd application that is pretty
> much like other user applications, but is partly implemented in the
> kernel
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 wrote:
> >
> >> I think we should have the option to log everything, and through a
> >> singel channel;
> >
> > 1. Or
Matt,
Am 26.02.2013 um 23:47 schrieb Matt Shaver:
> On Tue, 26 Feb 2013 21:19:53 +0100
> Michael Haberler 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
On Tue, 26 Feb 2013 21:19:53 +0100
Michael Haberler 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
On 2/26/2013 5:00 PM, Chris Radek wrote:
> I guess I just want us to consider what problem we are solving for
> the user before we decide on an architecture. I saw a lot of
> "obviously syslog!" and I didn't understand why we were jumping
> right to there, because it didn't seem to me that it solv
On Tue, Feb 26, 2013 at 02:02:44PM -0700, Sebastian Kuzminsky wrote:
>
> I agree that the bulk of our users don't know and don't care where the
> log files are, and that many of our messages need to pop up in the GUI.
> Whatever changes, if any, can't break GUI message popups.
Ideally they wo
On 2/26/13 13:19 , Michael Haberler wrote:
>
> Am 26.02.2013 um 18:15 schrieb Chris Radek:
>
>> On Tue, Feb 26, 2013 at 05:09:42PM +0100, Michael Haberler wrote:
>>>
>>> all messages should wind up in syslog anyway
>>
>> I don't agree with this. We have an odd application that is pretty
>
> Talk t
Am 26.02.2013 um 18:15 schrieb Chris Radek:
> On Tue, Feb 26, 2013 at 05:09:42PM +0100, Michael Haberler wrote:
>>
>> all messages should wind up in syslog anyway
>
> I don't agree with this. We have an odd application that is pretty
Talk that one out with Seb first, please.
I think we shoul
On Tue, Feb 26, 2013 at 05:09:42PM +0100, Michael Haberler wrote:
>
> all messages should wind up in syslog anyway
I don't agree with this. We have an odd application that is pretty
much like other user applications, but is partly implemented in the
kernel for technical reasons. If not for this
On Tuesday 26 February 2013 11:42:52 Gene Heskett did opine:
> On Tuesday 26 February 2013 11:27:12 Sebastian Kuzminsky did opine:
> > On 2/26/13 08:54 , Arvid Brodin wrote:
> > > On 2013-02-26 16:23, Sebastian Kuzminsky wrote:
> > >> On 02/26/2013 01:38 AM, Michael Haberler wrote:
> > >>> sim bui
On Tuesday 26 February 2013 11:27:12 Sebastian Kuzminsky did opine:
> On 2/26/13 08:54 , Arvid Brodin wrote:
> > On 2013-02-26 16:23, Sebastian Kuzminsky wrote:
> >> On 02/26/2013 01:38 AM, Michael Haberler wrote:
> >>> sim build:
> >>> - there is no /proc/rtapi/debug since sim builds dont sport k
On 2/26/13 08:54 , Arvid Brodin wrote:
> On 2013-02-26 16:23, Sebastian Kuzminsky wrote:
>> On 02/26/2013 01:38 AM, Michael Haberler wrote:
>>> sim build:
>>> - there is no /proc/rtapi/debug since sim builds dont sport kernel modules
>>> and hence no procfs/sysfs entries
>>> - the program which ru
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/
On 2013-02-26 16:23, Sebastian Kuzminsky wrote:
> On 02/26/2013 01:38 AM, Michael Haberler wrote:
>> 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
On 02/26/2013 01:38 AM, Michael Haberler wrote:
> 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 issu
On 26 February 2013 08:38, Michael Haberler wrote:
> - 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*).
There is also a scratch-writte
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
17 matches
Mail list logo
