Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Philippe Gerum wrote:
>>>>>>>>> config XENO_OPT_DEBUG_FOO
>>>>>>>>> 	bool "..."
>>>>>>>>>
>>>>>>>>> config XENO_OPT_DEBUG_FOO_P
>>>>>>>>> 	int
>>>>>>>>> 	default "1" if XENO_OPT_DEBUG_FOO
>>>>>>>>> 	default "0"
>>>>>>>>>
>>>>>>>>> and XENO_DEBUG() could be extended to test for
>>>>>>>>> CONFIG_XENO_OPT_DEBUG_FOO_P when given "FOO". I'm just not sure if this
>>>>>>>>> can be expressed for legacy 2.4 kernels, so it might have to wait for
>>>>>>>>> Xenomai 3.
>>>>>> Well, actually, I would not merge this in Xenomai 3. I find this rather
>>>>>> overkill; mainline first I mean, and mainline, i.e. the Xenomai code
>>>>>> base only requires a simple and straightforward way to get debug
>>>>>> switches right. Having to make Kconfig a kitchen sink for some unknown
>>>>>> out of tree modules to be happy is not really my preferred approach in
>>>>>> this particular case.
>>>>>>
>>>>>> Don't get me wrong, I'm not opposed to a more decentralized approach on
>>>>>> the paper, it's just that I only care about the mainline tree here.
>>>>> The point is not out-of-tree but robustness. Neither the current
>>>>> decentralized #ifdef-#define nor its centralized brother meet this
>>>>> criteria. An approach like the above which forces you to provide all
>>>>> required bits before any of the cases (disabled/enabled) starts to work
>>>>> does so.
>>>> Ok. What about:
>>>>
>>>> #define __name2(a, b) a ## b
>>>> #define name2(a, b) __name2(a, b)
>>>>
>>>> #define DECLARE_ASSERT_SYMBOL(sym)					\
>>>> 	static const int CONFIG_XENO_OPT_DEBUG_##sym##0 = 0,		\
>>>> 		__CONFIG_XENO_OPT_DEBUG_##sym = name2(CONFIG_XENO_OPT_DEBUG_##sym, 0)
>>>>
>>>> #define XENO_ASSERT(subsystem,cond,action)  do { \
>>>>     if (unlikely(__CONFIG_XENO_OPT_DEBUG_##subsystem > 0 && !(cond))) { \
>>>>         xnarch_trace_panic_freeze(); \
>>>>         xnlogerr("assertion failed at %s:%d (%s)\n", __FILE__, __LINE__, (#cond)); \
>>>>         xnarch_trace_panic_dump(); \
>>>>         action; \
>>>>     } \
>>>> } while(0)
>>>>
>>>> DECLARE_ASSERT_SYMBOL(NUCLEUS);
>>>>
>>>> It fails to compile when the debug symbol is set and
>>>> DECLARE_ASSERT_SYMBOL is missing, which plugs the failure of my previous
>>>> attempt.
>>> I'm still wrapping my head around this. What would be the usage,
>>>
>>> #ifndef CONFIG_XENO_OPT_DEBUG_FOO
>>> #define CONFIG_XENO_OPT_DEBUG_FOO 0
>>> #endif
>>>
>>> DECLARE_ASSERT_SYMBOL(FOO);
>>>
>>> ? If the compiler is smart enough to still drop the asserts based on
>>> static const, I'm fine as this is an improvement.
>> No, you just use DECLARE_ASSERT_SYMBOL(FOO)
> 
> Would be nice - if it worked.
> 
>>> Still, IMHO, this solution would not even win the second league beauty
>>> contest (now it comes with as many additional lines as the
>>> Kconfig-approach).
>> Yes, it is not pretty but to add a config option you just add the usual
>> Kconfig stuff, then DECLARE_ASSERT_SYMBOL in the code instead of the
>> #ifndef #define foo 0 #endif.
>>
>> If you do not do it, you get a compilation error whether the option is
>> enabled or not.
>>
>> It can be decentralized, the find | grep mentioned earlier will still work.
> 
> If we can make it work like that, I'm all for it. But:
> 
> error: initializer element is not constant
> (when disabled)

Right, I get this one. I only tested with the preprocessor.

> or
> 
> error: ‘y0’ undeclared here (not in a function)
> (when enabled)

However, it works for me when enabled. Trying harder now.

-- 
					    Gilles.