Re: [Xenomai-core] [PATCH] separate queue debugging switch

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>Hi,
>>>
>>>while XENO_OPT_DEBUG is generally a useful switch for tracing potential
>>>issues in the core and the skins, it also introduces high latencies via
>>>the queue debugging feature (due to checks iterating over whole queues).
>>>
>>>This patch introduces separate control over queue debugging so that you
>>>can have debug checks without too dramatic slowdowns.
>>>
>>
>>Maybe it's time to introduce debug levels, so that we could reuse them
>>in order to
>>add more (selectable) debug instrumentation; queue debugging could then
>>be given a
>>certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for
>>this one...), instead of going for a specific conditional each time we
>>introduce new checks?
>>
> 
> 
> Hmm, this means someone have to define what should be printed at which
> level - tend to be hard decisions... Often it is at least as much useful
> to have debug groups so that specific parts can be excluded from
> debugging. I'm pro such groups (one would be those queues e.g.) but
> contra too many levels (2, at most 3).
> 

Ack, selection by increasingly verbose/high-overhead groups is what I have in mind.

> At this chance, I would also suggest to introduce some ASSERT macro (per
> group, per level). That could be used to instrument the core with
> runtime checks. But it could also be quickly removed at compilation
> time, reducing the code size (e.g. checks at the nucleus layer against
> buggy skins or at RTDM layer against rough drivers).
>

I'm not opposed to that, if we keep the noise / signal ratio of those assertions 
at the reasonable low-level throughout the code, and don't use this to enforce 
silly parametrical checks.

> Jan
> 


-- 

Philippe.