Re: [Xenomai-core] [PATCH] provide ipipe_traceing via nucleus interface

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 4854 bytes --]

Philippe Gerum wrote:
> On Fri, 2006-06-23 at 11:27 +0200, Jan Kiszka wrote:
>>>> Index: include/nucleus/ipipe_trace.h
>>>> ===================================================================
>>> This file should go to include/asm-generic/ since it depends on the
>>> underlying real-time enabler (i.e. I-pipe). This way, there would be
>>> no need to check for __XENO_SIM__.
>> Ok, but how is the user supposed to include the API then? Or can we drag
>> it in implicitly somehow? That would be even nicer I think.
>>
> 
> asm-generic/trace.h would be dragged in by include/asm-<arch>/hal.h, so
> that we get the proper double dependancy on both the architecture if it
> does provide the tracing feature, and also on the HAL which in turn
> requires the I-pipe.

Err, asm-<arch>/hal.h are pure kernel space headers, aren't they? But we
need user space support as well.

> 
>>>> --- include/nucleus/ipipe_trace.h	(Revision 0)
>>>> +++ include/nucleus/ipipe_trace.h	(Revision 0)
>>>> @@ -0,0 +1,82 @@
>>>> +/*
>>>> Index: src/testsuite/latency/latency.c
>>>> ===================================================================
>>>> --- src/testsuite/latency/latency.c	(Revision 1252)
>>>> +++ src/testsuite/latency/latency.c	(Arbeitskopie)
>>>> @@ -12,6 +12,7 @@
>>>>  #include <native/timer.h>
>>>>  #include <native/sem.h>
>>>>  #include <rtdm/rttesting.h>
>>>> +#include <nucleus/ipipe_trace.h>
>>>>  
>>>>  RT_TASK latency_task, display_task;
>>>>  
>>>> @@ -130,8 +131,7 @@ void latency (void *cookie)
>>>>  
>>>>              if (freeze_max && (dt > gmaxjitter) && !(finished ||
>>> warmup))
>>>>                  {
>>>> -                rt_dev_ioctl(benchdev, RTBNCH_RTIOC_REFREEZE_TRACE,
>>>> -                             rt_timer_tsc2ns(dt));
>>>> +                ipipe_trace_refreeze(rt_timer_tsc2ns(dt));
>>> I don't like the idea of spreading ipipe-something symbols and
>>> dependancies all over the entire source code including the generic one,
>>> especially when considering that at some point, we are going to have
>>> preempt-rt as the other possible real-time enabler, like
>>> Adeos is already used now. We should use something more generic.
>>> "tracer*" would be ok, I guess.
>>>
>> I'm going to rescan Ingo's API to define a common interface where
>> feasible (their own user space API seems to hide behind gettimeofday).
> 
> Thanks. We should definitely consider the underlying the real-time
> enabling technology Xenomai uses to run skins over as an interchangeable
> component.
> 

Unfortunately, Ingo's semantics are still quite different, partly
incompatible (and unhandy as well - you can only trace one event, not
the worst of a series like with the ipipe tracer). So we may need
special user code to deal with these differences (like in cyclictest).

The most critical point is that Ingo's tracer nukes any timing
guarantees when it fires. In contrast, the ipipe variant is RT-safe.

Anyway, let's try to go for these names and semantics (implementation:
ipipe / Ingo):

xntrace_max_begin(unsigned long v):
	Mark the worst-case path beginning together with an arbitrary
	ulong. This path is separated from the user path below.

	ipipe_trace_begin(v); / -

xntrace_max_end(unsigned long v):
	Mark the worst-case path end together with an arbitrary ulong.
	The path with maximum length can be obtained from the logs.

	ipipe_trace_end(v); / -

xntrace_user_start(void):
	Start the user trace path.

	ipipe_trace_frozen_reset(); / user_trace_start();

xntrace_user_stop(unsigned long v):
	Record an arbitrary ulong and stop the user trace path. The
	result is kept until the next invocation of
	xntrace_user_start() or xntrace_user_freeze(..., 0).

	ipipe_trace_freeze(v); /
	trace_special(v, 0, 0); user_trace_stop();

xntrace_user_freeze(unsigned long v, int once):
	Record an arbitrary ulong and freeze the user trace path. If
	once is 0, the tracer keeps running after the freeze so that
	always the latest result can be obtained. Otherwise, this call
	is equivalent to xntrace_user_stop(v).

	if (once)
		xntrace_user_stop(v);
	else
		ipipe_trace_frozen_reset(); ipipe_trace_freeze(v) / -

xntrace_special(unsigned char id, unsigned long v):
	Record an arbitrary uchar + ulong.

	ipipe_trace_special(id, v); / trace_special(v, 0, id);

xntrace_special_u64(unsigned char id, unsigned long long v):
	Record an arbitrary uchar + u64.

	ipipe_trace_special(id, v >> 32);
	ipipe_trace_special(id, v & 0xFFFFFFFF); /
	trace_special_u64(v, id);

I choose xntrace as prefix because Xenomai is used here to provide an
abstraction layer. Do you agree with the naming? Then this API should be
made available symmetrically in both kernel and use space. Still, the
question is via which header file...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]