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)

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

-- 
                                            Gilles.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to