Re: [Xenomai-core] CONFIG_XENO_OPT_DEBUG_LEVEL

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

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

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, ...

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


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