Le 09/21/2012 10:21 AM, Herman Bruyninckx a écrit :
> On Fri, 21 Sep 2012, paul [dot] chavent [..] ... wrote:
>
>> Hi
>>
>> - application components (e.g., your "controller", "estimator",...)
>> -> It should be done by the end-user with the tools he prefers (taps in in code, printf, ...).
>> It should not be constrained, homogeneised, provided, ...
>
> I fully disagree! Maybe what you suggest is fine, but not in components
> that are released to others: they should get a standardized logging
> support.

You can wish to standardize this logging level, but it's not the job of rtt to care with that. I suggest to ignore this point in RTT.

>
>> - software framework components (RTT TaskContexts)
>> -> It should be an rtt compilation option.
>
> Or rather, a deployment option.

I will try to make a mockup based on lttng-ust for begining...

>
>> It could be implemented with simple code that measure time
>> (clock_get_time), and that store the timings in an array that is output
>> when the component is destroyed for instance.
>
> No! things like "clock_get_time" in components introduce subtle side
> effects, that prevent reuse. Time is a platform resource, and should be
> abstracted in a platform port, not in a function call inside component
> code.

:) don't worry, it shouldn't be too dificult to purpose a tracing service (like logging, activities, ...), that works with system calls (like printf and pthread_start) underthehood.

However, i didn't think to provide tracing as a service before your comment... I thought to trace every taskcontext when it enters its loop(). It could allow to make very basic checks on the timings as a first step.

I'm not convinced yet that tracing should be an rtt service...

>
>> It could also be implemented with http://lttng.org/ust, which is a userspace trace tool.
>> I'm not very familiar with others tools
>>
>> - operating system components (threads, processes, queues, locks,...)
>> -> It should be done by the system administrator. RTT could give some sample scenarii.
>> -> It could be done with [sd]trace, stap, ...
>>
>> - hardware components (busses, memory, CPUs, time).
>> -> It should be provided with the platform sdk. It's done in compinaison with osciloscopes or other hardware measurment
>>
>> In one word, RTT could provide on trace tool in the TaskContext for begining.
>
> Yes. But we should "standardize" on what are the RTT component-level features that should/could be traced.
>
>> Do you share this point of view ?
>>
>> P.S : i don't see this thread on the web interface of the forum...
>>
>> Paul.
>
> Herman
>
>>
>> ========================================
>> Message du 21/09/12 09:18
>> De : "Herman Bruyninckx"
>> A : "Paul Chavent"
>>
>> Copie à : orocos-dev [..] ...
>> Objet : Re: [Orocos-Dev] Trace tools
>>
>> On Thu, 20 Sep 2012, Paul Chavent wrote:
>>
>>> Hi.
>>>
>>> Is there anyone that have tried to integrate some trace tools to RTT
>>> (something like ltt) ? Do you have instrumented RTT with custom code ? Do
>>> you use strace or similar external tools ?
>>>
>>> Would you be interested in such integration in RTT (i think to something like ltt : http://lttng.org/ust) ?
>>
>> Absolutely! This has been on my radar since years, but I was not yet able
>> to motivate students or projects to spend time on this topic. (And a recent
>> FP7 project proposal on this topic was not approved :-( )
>>
>> Anyway, "tracing" must be provided at the (in the meantime, "clasical") different levels of components:
>> - application components (e.g., your "controller", "estimator",...)
>> - software framework components (RTT TaskContexts)
>> - operating system components (threads, processes, queues, locks,...)
>> - hardware components (busses, memory, CPUs, time).
>>
>> Lttng is only focussing on the OS components, but I am quite confident its
>> infrastructure could be reused for the other component levels. This
>> "separtion of concerns" will require a lot of care, though.
>>
>>> Regards.
>>>
>>> Paul.
>>
>> Herman
>>
>
> --
> KU Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

On Fri, Sep 21, 2012 at 10:21:45AM +0200, Herman Bruyninckx wrote:
> >- software framework components (RTT TaskContexts)   -> It should be an rtt
> >compilation option.
>
> Or rather, a deployment option.
>
> >       It could be implemented with simple code that measure time
> >(clock_get_time), and that store the timings in an array that is output
> >when the component is destroyed for instance.
>
> No! things like "clock_get_time" in components introduce subtle side
> effects, that prevent reuse. Time is a platform resource, and should be
> abstracted in a platform port, not in a function call inside component
> code.
>
> >       It could also be implemented with http://lttng.org/ust, which is a userspace trace tool.
> >       I'm not very familiar with others tools

A nice example of such tool is the instrumentation framework of QNX. It is not
open-source, but have a detailed documentation and the implementation is
"real-time friendly."

On Fri, Sep 21, 2012 at 10:21:45AM +0200, Herman Bruyninckx wrote:

> >       It could be implemented with simple code that measure time
> >(clock_get_time), and that store the timings in an array that is output
> >when the component is destroyed for instance.
>
> No! things like "clock_get_time" in components introduce subtle side
> effects, that prevent reuse. Time is a platform resource, and should be
> abstracted in a platform port, not in a function call inside component
> code.

But clock_gettime(2) is a platform port. The platform is POSIX!

Markus