Re: [Xenomai-core] CONFIG_XENO_OPT_DEBUG_LEVEL

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>Hi,
>>>
>>>as I started to actually use XENO_ASSERT, I noticed that there is no
>>>infrastructure yet to enable it. CONFIG_XENO_OPT_DEBUG_LEVEL is nowhere
>>>defined. Add this as integer to Kconfig? Or better convert
>>>nucleus/assert.h to CONFIG_OPT_DEBUG for now until we really feel like
>>>we need more than on/off for this? I would vote for the latter ATM.
>>
>>Actually, we already need more than a simple switch: I'd really like the
>>queue debugging option to become a level on its own (say, 4294967295?).
>>I'll add this tomorrow.
> 
> 
> Hmm, raises my old concern again: this "vertical" debugging implies to
> switch everything on when you only want queue debugging. I still think
> we rather need "horizontal" control: switch on queues, asserts, ...

It just depends whether we want to make the assertion mechanism a 
formalized exported feature or not. If there is a limited number of 
"clients", the simpler the better. This said, implementing sub-system 
debug switches instead of global debug levels would still be pretty 
trivial, provided we keep the number of sub-systems within reasonable 
limits (e.g. <= 64).

> 
> This level "4294967295" indicates for me where we may end with: dozens
> of debug levels no one can tell apart, and you have to switch them all
> on to gain the relevant pieces or to be sure that you didn't missed
> anything. I always have the mess in mind we once had in ndiswrapper: for
> serious debugging of the USB layer you had to raise the debug level
> which dragged in bulks of (in this case) useless reports from other
> subsystems.
> 
> A student (Marc Kleine-Budde) once ported some nice debug subsystem into
> an internal project that requested a subsystem ID for every debug
> statement (I think it came from kaffe). At compilation time or even
> later during runtime you could easily select which subsystem should
> start babbling and checking and which one is not that interesting for a
> specific test. I think this is far more useful than debug levels. Queues
> could become such a subsystem, RTDM (with its asserts) another, and so
> forth. Of course, this means maintaining those subsystem IDs at a
> central place, but it's clearer than deciding which level to pick for a
> new debug code.
> 
> Jan
> 


-- 

Philippe.