Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote: > This is complemented by a check_script whose result on the previous > xenomai version you can see at: > http://sisyphus.hd.free.fr/~gilles/bx/distcheck/xenomai/log.html Moved it to: http://sisyphus.hd.free.fr/~gilles/pastebin/wcZMMi to be able to run the build-test on master. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Hi, >> >> I found some code which was referencing directly some >> CONFIG_XENO_OPT_DEBUG_ variables with things like: >> >> #ifdef CONFIG_XENO_OPT_DEBUG_FOO >> >> This usage is incompatible with the pre-requisites of the assert.h >> header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. >> While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have >> many duplicates of construction like: >> #ifndef CONFIG_XENO_OPT_DEBUG_FOO >> #define CONFIG_XENO_OPT_DEBUG_FOO 0 >> #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ >> >> So, a patch follows which: >> - replace the #ifdef with some #if XENO_DEBUG(FOO) > > Should probably come as a separate patch. > >> - move all the initializations to assert.h >> >> This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of >> assert.h suspicious, and easy to detect. > > How many duplicates did you find? > > Generally, I'm more a fan of decentralized management here (e.g. this > avoids needless patch conflicts in central files). My latest approach was not really working (it was working, but generated warning when compiled with -Wundef, and the kernel is compiled with -Wundef). So, let us stop the madness. I have merged the following solution: - fixed the direct references to CONFIG_XENO_OPT_DEBUG_FOO and replaced them with XENO_DEBUG(FOO) - moved the duplicate CONFIG_XENO_OPT_DEBUG_FOO initializations which did not fit to a particular file to assert.h (actually only QUEUES and NUCLEUS), let the other initializations live in peace where they were. This is complemented by a check_script whose result on the previous xenomai version you can see at: http://sisyphus.hd.free.fr/~gilles/bx/distcheck/xenomai/log.html -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Jan Kiszka wrote: > diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh > index 24b1f17..d8038e0 100755 > Please let me know what precisely you dislike in this approach. You have to re-run prepare-kernel when you modify the source. >>> Normally, you have to anyway as you add some header or some other source >>> file during this process. >> Not necessarily. > > At worst, you run into a build error and repeat the step. Otherwise, the > next installation will fix it silently. It's much like the missing > DECLARE_ASSERT_SYMBOL detection and resolution, IMO even more convenient. I do not see in what way it is more convenient. I would now have to run prepare-kernel.sh in a case when I did not have to run it. Adding DECLARE_ASSERT_SYMBOL to one .c file just triggers the recompilation of the file, and relinking of the kernel. > I do not like dynamic sources generation. Especially when we have a working solution based on C pre-processor macros. >>> My prepare-kernel approach also detects stall debug stuff: The uitron >>> use of XENO_DEBUG is not backed by any config option. >> The current candidate would also detect the missing >> DECLARE_ASSERT_SYMBOL in that case. >> > > But not > > #if XENO_DEBUG(DOES_NOT_EXIST) This can be made during the build-test and thus avoided during a normal compilation. I am really, strongly opposed to dynamic code generation. Especially which greps the whole source tree, this is a waste of cpu power. Most shell scripts are wrong when first written and do not handle errors correctly. I already see two or three pitfalls in the script you proposed. Globally, this is really overkill and risky. The alternative, a 3 lines C macro, has the inconvenient of requiring that we declare the symbol, but after all the original solution had the same, and nobody complained. We do not add debug symbols that often. What is important however, is that we avoid the current mess which happened in pod.h and pod.c because they used #ifdef CONFIG_XENO_OPT_DEBUG_NUCLEUS, and this macro solution allows to detect such issues.. We can add the missing features of this solution in the build-test script. This way there is 0 impact on the compilation for end-users. And since we do run the build-test script, we are sure not to miss any error. And if the scripts erases xenomai sources directory because of flaky error checking, it will only erase my xenomai sources. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
My compiler still complains about undefined 'y0' in the enabled case.
I'll try to dig into a different direction now: Automatic generation
during build. This is what the kernel does as well when the
preprocessor
gives up. Would even save the DECLARE and should make everyone happy.
>>> No, please nothing like that.
>> Because ... ?
>>
>> BTW, I'll extend the prepare stage. Defining the proper dependencies for
>> build-time generation gets too hairy.
>>
>>> This one works for me:
>>> #include
>>> #include
>>>
>>> #define __name2(a, b) a ## b
>>> #define name2(a, b) __name2(a, b)
>>>
>>> #define DECLARE_ASSERT_SYMBOL(sym)
>>> \
>>> static const int XENO_OPT_DEBUG_##sym = 0; \
>>> static const int CONFIG_XENO_OPT_DEBUG_##sym##0 = 0
>>>
>>> #define XENO_DEBUG(sym) \
>>> (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > XENO_OPT_DEBUG_##sym)
>>>
>>> #define XENO_ASSERT(subsystem,cond,action) do { \
>>> if (unlikely(XENO_DEBUG(subsystem) && !(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);
>>>
>>> int main(void)
>>> {
>>> if (XENO_DEBUG(NUCLEUS))
>>> printf("Hello\n");
>>> }
>>>
>>> Please try and send me the result of pre-processing if
>>> it does not work for you.
>>>
>> Find it attached.
> It looks like you are defining CONFIG_XENO_OPT_DEBUG_NUCLEUS to be y
> instead of 1.
Right, my bad.
Works now, just leaving a trace when optimization is off.
>>> I believe the current approach would have the same problem. And in any
>> Nope, it's a pure preprocessor approach.
>
> When you use if(XENO_DEBUG(foo)) you are using the compiler, not the
> preprocessor.
Right from that POV. XENO_DEBUG(foo) itself remains preprocessor stuff,
ie. never includes potentially non-static expressions. But this part is
academic if -O0 fails to build the kernel.
>
> To see if there is a difference, you should try #if XENO_DEBUG(foo). And
> from what I see, in that case I do not have any trace of anything generated.
>
diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh
index 24b1f17..d8038e0 100755
Please let me know what precisely you dislike in this approach.
>>> You have to re-run prepare-kernel when you modify the source.
>> Normally, you have to anyway as you add some header or some other source
>> file during this process.
>
> Not necessarily.
At worst, you run into a build error and repeat the step. Otherwise, the
next installation will fix it silently. It's much like the missing
DECLARE_ASSERT_SYMBOL detection and resolution, IMO even more convenient.
>
>>> I do not like dynamic sources generation. Especially when we have a
>>> working solution based on C pre-processor macros.
>>>
>> My prepare-kernel approach also detects stall debug stuff: The uitron
>> use of XENO_DEBUG is not backed by any config option.
>
> The current candidate would also detect the missing
> DECLARE_ASSERT_SYMBOL in that case.
>
But not
#if XENO_DEBUG(DOES_NOT_EXIST)
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Jan Kiszka wrote: > My prepare-kernel approach also detects stall debug stuff: The uitron > use of XENO_DEBUG is not backed by any config option. This can be checked when we do the build-test, this will be much more economic. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> My compiler still complains about undefined 'y0' in the enabled case.
>>>
>>> I'll try to dig into a different direction now: Automatic generation
>>> during build. This is what the kernel does as well when the preprocessor
>>> gives up. Would even save the DECLARE and should make everyone happy.
>> No, please nothing like that.
> Because ... ?
>
> BTW, I'll extend the prepare stage. Defining the proper dependencies for
> build-time generation gets too hairy.
>
>> This one works for me:
>> #include
>> #include
>>
>> #define __name2(a, b) a ## b
>> #define name2(a, b) __name2(a, b)
>>
>> #define DECLARE_ASSERT_SYMBOL(sym) \
>> static const int XENO_OPT_DEBUG_##sym = 0; \
>> static const int CONFIG_XENO_OPT_DEBUG_##sym##0 = 0
>>
>> #define XENO_DEBUG(sym) \
>> (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > XENO_OPT_DEBUG_##sym)
>>
>> #define XENO_ASSERT(subsystem,cond,action) do { \
>> if (unlikely(XENO_DEBUG(subsystem) && !(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);
>>
>> int main(void)
>> {
>> if (XENO_DEBUG(NUCLEUS))
>> printf("Hello\n");
>> }
>>
>> Please try and send me the result of pre-processing if
>> it does not work for you.
>>
> Find it attached.
It looks like you are defining CONFIG_XENO_OPT_DEBUG_NUCLEUS to be y
instead of 1.
>>> Right, my bad.
>>>
>>> Works now, just leaving a trace when optimization is off.
>> I believe the current approach would have the same problem. And in any
>
> Nope, it's a pure preprocessor approach.
When you use if(XENO_DEBUG(foo)) you are using the compiler, not the
preprocessor.
To see if there is a difference, you should try #if XENO_DEBUG(foo). And
from what I see, in that case I do not have any trace of anything generated.
>>> diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh
>>> index 24b1f17..d8038e0 100755
>>> Please let me know what precisely you dislike in this approach.
>> You have to re-run prepare-kernel when you modify the source.
>
> Normally, you have to anyway as you add some header or some other source
> file during this process.
Not necessarily.
>> I do not like dynamic sources generation. Especially when we have a
>> working solution based on C pre-processor macros.
>>
>
> My prepare-kernel approach also detects stall debug stuff: The uitron
> use of XENO_DEBUG is not backed by any config option.
The current candidate would also detect the missing
DECLARE_ASSERT_SYMBOL in that case.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> My compiler still complains about undefined 'y0' in the enabled case.
>>
>> I'll try to dig into a different direction now: Automatic generation
>> during build. This is what the kernel does as well when the preprocessor
>> gives up. Would even save the DECLARE and should make everyone happy.
> No, please nothing like that.
Because ... ?
BTW, I'll extend the prepare stage. Defining the proper dependencies for
build-time generation gets too hairy.
> This one works for me:
> #include
> #include
>
> #define __name2(a, b) a ## b
> #define name2(a, b) __name2(a, b)
>
> #define DECLARE_ASSERT_SYMBOL(sym) \
> static const int XENO_OPT_DEBUG_##sym = 0; \
> static const int CONFIG_XENO_OPT_DEBUG_##sym##0 = 0
>
> #define XENO_DEBUG(sym) \
> (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > XENO_OPT_DEBUG_##sym)
>
> #define XENO_ASSERT(subsystem,cond,action) do { \
> if (unlikely(XENO_DEBUG(subsystem) && !(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);
>
> int main(void)
> {
> if (XENO_DEBUG(NUCLEUS))
> printf("Hello\n");
> }
>
> Please try and send me the result of pre-processing if
> it does not work for you.
>
Find it attached.
>>> It looks like you are defining CONFIG_XENO_OPT_DEBUG_NUCLEUS to be y
>>> instead of 1.
>> Right, my bad.
>>
>> Works now, just leaving a trace when optimization is off.
>
> I believe the current approach would have the same problem. And in any
Nope, it's a pure preprocessor approach.
> case the kernel is never compiled without optimization, some other
> things break in that case.
>
>> But as it still requires explicit declaration, I'm more in favor of
>> (...)
>>
>> diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh
>> index 24b1f17..d8038e0 100755
>> Please let me know what precisely you dislike in this approach.
>
> You have to re-run prepare-kernel when you modify the source.
Normally, you have to anyway as you add some header or some other source
file during this process.
> And if you run it for every compilation, it wil slow the compilation down.
> And you will have to add some tricks to avoid touching the generated
> file if its contents did not change to avoid a full re-compilation.
> And if you do all that you will end-up at best with 20 lines of shell.
>
> The current candidate is 3 lines of C macro + 1 line per debug symbol.
The changes to assert.h do not matter that much. More important is that
you do not need to bother about adding the declare somewhere.
>
> I do not like dynamic sources generation. Especially when we have a
> working solution based on C pre-processor macros.
>
My prepare-kernel approach also detects stall debug stuff: The uitron
use of XENO_DEBUG is not backed by any config option.
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
> My compiler still complains about undefined 'y0' in the enabled case.
>
> I'll try to dig into a different direction now: Automatic generation
> during build. This is what the kernel does as well when the preprocessor
> gives up. Would even save the DECLARE and should make everyone happy.
No, please nothing like that.
>>> Because ... ?
>>>
>>> BTW, I'll extend the prepare stage. Defining the proper dependencies for
>>> build-time generation gets too hairy.
>>>
This one works for me:
#include
#include
#define __name2(a, b) a ## b
#define name2(a, b) __name2(a, b)
#define DECLARE_ASSERT_SYMBOL(sym) \
static const int XENO_OPT_DEBUG_##sym = 0; \
static const int CONFIG_XENO_OPT_DEBUG_##sym##0 = 0
#define XENO_DEBUG(sym) \
(name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > XENO_OPT_DEBUG_##sym)
#define XENO_ASSERT(subsystem,cond,action) do { \
if (unlikely(XENO_DEBUG(subsystem) && !(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);
int main(void)
{
if (XENO_DEBUG(NUCLEUS))
printf("Hello\n");
}
Please try and send me the result of pre-processing if
it does not work for you.
>>> Find it attached.
>> It looks like you are defining CONFIG_XENO_OPT_DEBUG_NUCLEUS to be y
>> instead of 1.
>
> Right, my bad.
>
> Works now, just leaving a trace when optimization is off.
I believe the current approach would have the same problem. And in any
case the kernel is never compiled without optimization, some other
things break in that case.
> But as it still requires explicit declaration, I'm more in favor of
> (...)
>
> diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh
> index 24b1f17..d8038e0 100755
> Please let me know what precisely you dislike in this approach.
You have to re-run prepare-kernel when you modify the source.
And if you run it for every compilation, it wil slow the compilation down.
And you will have to add some tricks to avoid touching the generated
file if its contents did not change to avoid a full re-compilation.
And if you do all that you will end-up at best with 20 lines of shell.
The current candidate is 3 lines of C macro + 1 line per debug symbol.
I do not like dynamic sources generation. Especially when we have a
working solution based on C pre-processor macros.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
My compiler still complains about undefined 'y0' in the enabled case.
I'll try to dig into a different direction now: Automatic generation
during build. This is what the kernel does as well when the preprocessor
gives up. Would even save the DECLARE and should make everyone happy.
>>> No, please nothing like that.
>> Because ... ?
>>
>> BTW, I'll extend the prepare stage. Defining the proper dependencies for
>> build-time generation gets too hairy.
>>
>>> This one works for me:
>>> #include
>>> #include
>>>
>>> #define __name2(a, b) a ## b
>>> #define name2(a, b) __name2(a, b)
>>>
>>> #define DECLARE_ASSERT_SYMBOL(sym) \
>>> static const int XENO_OPT_DEBUG_##sym = 0; \
>>> static const int CONFIG_XENO_OPT_DEBUG_##sym##0 = 0
>>>
>>> #define XENO_DEBUG(sym) \
>>> (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > XENO_OPT_DEBUG_##sym)
>>>
>>> #define XENO_ASSERT(subsystem,cond,action) do { \
>>> if (unlikely(XENO_DEBUG(subsystem) && !(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);
>>>
>>> int main(void)
>>> {
>>> if (XENO_DEBUG(NUCLEUS))
>>> printf("Hello\n");
>>> }
>>>
>>> Please try and send me the result of pre-processing if
>>> it does not work for you.
>>>
>> Find it attached.
>
> It looks like you are defining CONFIG_XENO_OPT_DEBUG_NUCLEUS to be y
> instead of 1.
Right, my bad.
Works now, just leaving a trace when optimization is off.
But as it still requires explicit declaration, I'm more in favor of
diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh
index 24b1f17..d8038e0 100755
--- a/scripts/prepare-kernel.sh
+++ b/scripts/prepare-kernel.sh
@@ -584,6 +584,17 @@ for d in include/* ; do
fi
done
+kconfigs=`find $xenomai_root/ksrc -name Kconfig`
+debug_defines=$linux_tree/include/xenomai/nucleus/debug_defines.h
+rm -f $debug_defines
+for debugopt in `grep XENO_OPT_DEBUG_ $kconfigs | cut -d' ' -f2`; do
+cat >>$debug_defines <
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> My compiler still complains about undefined 'y0' in the enabled case.
>>>
>>> I'll try to dig into a different direction now: Automatic generation
>>> during build. This is what the kernel does as well when the preprocessor
>>> gives up. Would even save the DECLARE and should make everyone happy.
>> No, please nothing like that.
>
> Because ... ?
>
> BTW, I'll extend the prepare stage. Defining the proper dependencies for
> build-time generation gets too hairy.
>
>> This one works for me:
>> #include
>> #include
>>
>> #define __name2(a, b) a ## b
>> #define name2(a, b) __name2(a, b)
>>
>> #define DECLARE_ASSERT_SYMBOL(sym) \
>> static const int XENO_OPT_DEBUG_##sym = 0; \
>> static const int CONFIG_XENO_OPT_DEBUG_##sym##0 = 0
>>
>> #define XENO_DEBUG(sym) \
>> (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > XENO_OPT_DEBUG_##sym)
>>
>> #define XENO_ASSERT(subsystem,cond,action) do { \
>> if (unlikely(XENO_DEBUG(subsystem) && !(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);
>>
>> int main(void)
>> {
>> if (XENO_DEBUG(NUCLEUS))
>> printf("Hello\n");
>> }
>>
>> Please try and send me the result of pre-processing if
>> it does not work for you.
>>
>
> Find it attached.
It looks like you are defining CONFIG_XENO_OPT_DEBUG_NUCLEUS to be y
instead of 1.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> My compiler still complains about undefined 'y0' in the enabled case.
>>
>> I'll try to dig into a different direction now: Automatic generation
>> during build. This is what the kernel does as well when the preprocessor
>> gives up. Would even save the DECLARE and should make everyone happy.
>
> No, please nothing like that.
Because ... ?
BTW, I'll extend the prepare stage. Defining the proper dependencies for
build-time generation gets too hairy.
>
> This one works for me:
> #include
> #include
>
> #define __name2(a, b) a ## b
> #define name2(a, b) __name2(a, b)
>
> #define DECLARE_ASSERT_SYMBOL(sym) \
> static const int XENO_OPT_DEBUG_##sym = 0; \
> static const int CONFIG_XENO_OPT_DEBUG_##sym##0 = 0
>
> #define XENO_DEBUG(sym) \
> (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > XENO_OPT_DEBUG_##sym)
>
> #define XENO_ASSERT(subsystem,cond,action) do { \
> if (unlikely(XENO_DEBUG(subsystem) && !(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);
>
> int main(void)
> {
> if (XENO_DEBUG(NUCLEUS))
> printf("Hello\n");
> }
>
> Please try and send me the result of pre-processing if
> it does not work for you.
>
Find it attached.
Jan
# 1 "test-debug1.c"
# 1 ""
# 1 ""
# 1 "test-debug1.c"
# 1 "/usr/include/stdlib.h" 1 3 4
# 25 "/usr/include/stdlib.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 330 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 348 "/usr/include/sys/cdefs.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 349 "/usr/include/sys/cdefs.h" 2 3 4
# 331 "/usr/include/features.h" 2 3 4
# 354 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 5 "/usr/include/gnu/stubs.h" 2 3 4
# 1 "/usr/include/gnu/stubs-64.h" 1 3 4
# 10 "/usr/include/gnu/stubs.h" 2 3 4
# 355 "/usr/include/features.h" 2 3 4
# 26 "/usr/include/stdlib.h" 2 3 4
# 1 "/usr/lib64/gcc/x86_64-suse-linux/4.3/include/stddef.h" 1 3 4
# 214 "/usr/lib64/gcc/x86_64-suse-linux/4.3/include/stddef.h" 3 4
typedef long unsigned int size_t;
# 326 "/usr/lib64/gcc/x86_64-suse-linux/4.3/include/stddef.h" 3 4
typedef int wchar_t;
# 34 "/usr/include/stdlib.h" 2 3 4
# 96 "/usr/include/stdlib.h" 3 4
typedef struct
{
int quot;
int rem;
} div_t;
typedef struct
{
long int quot;
long int rem;
} ldiv_t;
# 140 "/usr/include/stdlib.h" 3 4
extern size_t __ctype_get_mb_cur_max (void) __attribute__ ((__nothrow__)) ;
extern double atof (__const char *__nptr)
__attribute__ ((__nothrow__)) __attribute__ ((__pure__)) __attribute__
((__nonnull__ (1))) ;
extern int atoi (__const char *__nptr)
__attribute__ ((__nothrow__)) __attribute__ ((__pure__)) __attribute__
((__nonnull__ (1))) ;
extern long int atol (__const char *__nptr)
__attribute__ ((__nothrow__)) __attribute__ ((__pure__)) __attribute__
((__nonnull__ (1))) ;
__extension__ extern long long int atoll (__const char *__nptr)
__attribute__ ((__nothrow__)) __attribute__ ((__pure__)) __attribute__
((__nonnull__ (1))) ;
extern double strtod (__const char *__restrict __nptr,
char **__restrict __endptr)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1))) ;
# 182 "/usr/include/stdlib.h" 3 4
extern long int strtol (__const char *__restrict __nptr,
char **__restrict __endptr, int __base)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1))) ;
extern unsigned long int strtoul (__const char *__restrict __nptr,
char **__restrict __endptr, int __base)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1))) ;
__extension__
extern long long int strtoq (__const char *__restrict __nptr,
char **__restrict __endptr, int __base)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1))) ;
__extension__
extern unsigned long long int strtouq (__const char *__restrict __nptr,
char **__restrict __endptr, int __base)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1))) ;
__extension__
extern long long int strtoll (__const char *__restrict __nptr,
char **__restrict __endptr, int __base)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1))) ;
__extension__
extern unsigned long long int strtoull (__const char *__restrict __nptr,
char **__restrict __endptr, int __base)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1))) ;
# 311 "/usr/include/stdlib.h" 3 4
extern char *l64a (long int __n) __attribute__ ((__nothrow__)) ;
extern long int a64l (__const char *__s)
__attribute__ ((__nothrow__)) __attribute__ ((__pure__)) __attribute__
((__nonnull__ (1))) ;
# 1 "/
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Gilles Chanteperdrix wrote:
>>> 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)
or
error: ‘y0’ undeclared here (not in a function)
(when enabled)
I'm afraid the preprocessor is not powerful enough for this task (we
would need macros that include preprocessor conditionals).
>>> The following seems to work for me:
>>>
>>> #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
>>>
>>> #define XENO_DEBUG(sym) (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > 0)
>>>
>>> #define XENO_ASSERT(subsystem,cond,action) do { \
>>> if (unlikely(XENO_DEBUG(subsystem) && !(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);
>>>
>> We only loose the detection of the debug symbol used and not declared if
>> it is enabled. But this looks to me like a minor issue. Still trying though.
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> 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)
>>>
>>> or
>>>
>>> error: ‘y0’ undeclared here (not in a function)
>>> (when enabled)
>>>
>>> I'm afraid the preprocessor is not powerful enough for this task (we
>>> would need macros that include preprocessor conditionals).
>> The following seems to work for me:
>>
>> #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
>>
>> #define XENO_DEBUG(sym) (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > 0)
>>
>> #define XENO_ASSERT(subsystem,cond,action) do { \
>> if (unlikely(XENO_DEBUG(subsystem) && !(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);
>>
>
> We only loose the detection of the debug symbol used and not declared if
> it is enabled. But this looks to me like a minor issue. Still trying though.
>
My compiler still complains about undefined 'y0' in the enabled case.
I'll try to dig into a different direction now: Automatic generation
during build. This is what the kernel does as wel
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote:
> 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)
>>
>> or
>>
>> error: ‘y0’ undeclared here (not in a function)
>> (when enabled)
>>
>> I'm afraid the preprocessor is not powerful enough for this task (we
>> would need macros that include preprocessor conditionals).
>
> The following seems to work for me:
>
> #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
>
> #define XENO_DEBUG(sym) (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > 0)
>
> #define XENO_ASSERT(subsystem,cond,action) do { \
> if (unlikely(XENO_DEBUG(subsystem) && !(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);
>
We only loose the detection of the debug symbol used and not declared if
it is enabled. But this looks to me like a minor issue. Still trying though.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
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)
>
> or
>
> error: ‘y0’ undeclared here (not in a function)
> (when enabled)
>
> I'm afraid the preprocessor is not powerful enough for this task (we
> would need macros that include preprocessor conditionals).
The following seems to work for me:
#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
#define XENO_DEBUG(sym) (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > 0)
#define XENO_ASSERT(subsystem,cond,action) do { \
if (unlikely(XENO_DEBUG(subsystem) && !(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);
>
> Jan
>
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
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)
or
error: ‘y0’ undeclared here (not in a function)
(when enabled)
I'm afraid the preprocessor is not powerful enough for this task (we
would need macros that include preprocessor conditionals).
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
On Mon, 2010-04-19 at 19:22 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Mon, 2010-04-19 at 18:25 +0200, Philippe Gerum wrote: > >> On Mon, 2010-04-19 at 18:14 +0200, Jan Kiszka wrote: > >>> Philippe Gerum wrote: > On Mon, 2010-04-19 at 17:58 +0200, Jan Kiszka wrote: > > Gilles Chanteperdrix wrote: > >> Jan Kiszka wrote: > >>> Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > Gilles Chanteperdrix wrote: > >> Jan Kiszka wrote: > >>> Gilles Chanteperdrix wrote: > Hi, > > I found some code which was referencing directly some > CONFIG_XENO_OPT_DEBUG_ variables with things like: > > #ifdef CONFIG_XENO_OPT_DEBUG_FOO > > This usage is incompatible with the pre-requisites of the > assert.h > header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all > times. > While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also > have > many duplicates of construction like: > #ifndef CONFIG_XENO_OPT_DEBUG_FOO > #define CONFIG_XENO_OPT_DEBUG_FOO 0 > #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ > > So, a patch follows which: > - replace the #ifdef with some #if XENO_DEBUG(FOO) > >>> Should probably come as a separate patch. > >> Come on, the patch is simple, one patch for this is enough. > > One part is an obvious fix, the other a refactoring under > > discussion. > > > - move all the initializations to assert.h > > This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO > outside of > assert.h suspicious, and easy to detect. > >>> How many duplicates did you find? > >> A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS > > That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were > > misplaced. > > Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but > > tons > > of proper users. I don't see such an immediate need. > > > > When adding this kind of switching, it's till more handy to have > > things > > locally in your subsystem. That also makes reviewing easier when you > > only find changes in files that belong to a subsystem. > That is not the main point, the main point is that putting all these > defines in one files allow to detect easily direct references to the > symbols. > > >>> Generally, I'm more a fan of decentralized management here (e.g. > >>> this > >>> avoids needless patch conflicts in central files). > >> If we maintain the list in alphabetical order (which I have done), > >> we > >> reduce the likeliness for conflicts. The aim of doing this is also > >> that > >> I can check that the sources are clean with: > >> > >> find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep > >> CONFIG_XENO_OPT_DEBUG_ > >> > >> And that I can add this test to the automated build test. > >> > >> Note that forgetting to add a #define to the list yields an > >> immediate > >> compilation error. So, the patch makes things completely safe. > > What did you change to make this happen (for new users of > > XENO_DEBUG)? > Nothing. If you forget to add the define, and do not enable the debug > option (which everybody does most of the time), you get a compilation > error. > >>> The alternative (and decentralized) approach for fixing this consists > >>> of > >>> Kconfig magic for generating the value: > >>> > >>> 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 n
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
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
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
On Mon, 2010-04-19 at 19:22 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Mon, 2010-04-19 at 18:25 +0200, Philippe Gerum wrote: > >> On Mon, 2010-04-19 at 18:14 +0200, Jan Kiszka wrote: > >>> Philippe Gerum wrote: > On Mon, 2010-04-19 at 17:58 +0200, Jan Kiszka wrote: > > Gilles Chanteperdrix wrote: > >> Jan Kiszka wrote: > >>> Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > Gilles Chanteperdrix wrote: > >> Jan Kiszka wrote: > >>> Gilles Chanteperdrix wrote: > Hi, > > I found some code which was referencing directly some > CONFIG_XENO_OPT_DEBUG_ variables with things like: > > #ifdef CONFIG_XENO_OPT_DEBUG_FOO > > This usage is incompatible with the pre-requisites of the > assert.h > header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all > times. > While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also > have > many duplicates of construction like: > #ifndef CONFIG_XENO_OPT_DEBUG_FOO > #define CONFIG_XENO_OPT_DEBUG_FOO 0 > #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ > > So, a patch follows which: > - replace the #ifdef with some #if XENO_DEBUG(FOO) > >>> Should probably come as a separate patch. > >> Come on, the patch is simple, one patch for this is enough. > > One part is an obvious fix, the other a refactoring under > > discussion. > > > - move all the initializations to assert.h > > This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO > outside of > assert.h suspicious, and easy to detect. > >>> How many duplicates did you find? > >> A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS > > That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were > > misplaced. > > Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but > > tons > > of proper users. I don't see such an immediate need. > > > > When adding this kind of switching, it's till more handy to have > > things > > locally in your subsystem. That also makes reviewing easier when you > > only find changes in files that belong to a subsystem. > That is not the main point, the main point is that putting all these > defines in one files allow to detect easily direct references to the > symbols. > > >>> Generally, I'm more a fan of decentralized management here (e.g. > >>> this > >>> avoids needless patch conflicts in central files). > >> If we maintain the list in alphabetical order (which I have done), > >> we > >> reduce the likeliness for conflicts. The aim of doing this is also > >> that > >> I can check that the sources are clean with: > >> > >> find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep > >> CONFIG_XENO_OPT_DEBUG_ > >> > >> And that I can add this test to the automated build test. > >> > >> Note that forgetting to add a #define to the list yields an > >> immediate > >> compilation error. So, the patch makes things completely safe. > > What did you change to make this happen (for new users of > > XENO_DEBUG)? > Nothing. If you forget to add the define, and do not enable the debug > option (which everybody does most of the time), you get a compilation > error. > >>> The alternative (and decentralized) approach for fixing this consists > >>> of > >>> Kconfig magic for generating the value: > >>> > >>> 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 n
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Philippe Gerum wrote: > On Mon, 2010-04-19 at 18:25 +0200, Philippe Gerum wrote: >> On Mon, 2010-04-19 at 18:14 +0200, Jan Kiszka wrote: >>> Philippe Gerum wrote: On Mon, 2010-04-19 at 17:58 +0200, Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: Hi, I found some code which was referencing directly some CONFIG_XENO_OPT_DEBUG_ variables with things like: #ifdef CONFIG_XENO_OPT_DEBUG_FOO This usage is incompatible with the pre-requisites of the assert.h header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have many duplicates of construction like: #ifndef CONFIG_XENO_OPT_DEBUG_FOO #define CONFIG_XENO_OPT_DEBUG_FOO 0 #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ So, a patch follows which: - replace the #ifdef with some #if XENO_DEBUG(FOO) >>> Should probably come as a separate patch. >> Come on, the patch is simple, one patch for this is enough. > One part is an obvious fix, the other a refactoring under discussion. > - move all the initializations to assert.h This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of assert.h suspicious, and easy to detect. >>> How many duplicates did you find? >> A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS > That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were > misplaced. > Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but > tons > of proper users. I don't see such an immediate need. > > When adding this kind of switching, it's till more handy to have > things > locally in your subsystem. That also makes reviewing easier when you > only find changes in files that belong to a subsystem. That is not the main point, the main point is that putting all these defines in one files allow to detect easily direct references to the symbols. >>> Generally, I'm more a fan of decentralized management here (e.g. >>> this >>> avoids needless patch conflicts in central files). >> If we maintain the list in alphabetical order (which I have done), >> we >> reduce the likeliness for conflicts. The aim of doing this is also >> that >> I can check that the sources are clean with: >> >> find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep >> CONFIG_XENO_OPT_DEBUG_ >> >> And that I can add this test to the automated build test. >> >> Note that forgetting to add a #define to the list yields an immediate >> compilation error. So, the patch makes things completely safe. > What did you change to make this happen (for new users of XENO_DEBUG)? Nothing. If you forget to add the define, and do not enable the debug option (which everybody does most of the time), you get a compilation error. >>> The alternative (and decentralized) approach for fixing this consists of >>> Kconfig magic for generating the value: >>> >>> 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. >> Flexibility and robustness have to be
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
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.
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).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
On Mon, 2010-04-19 at 18:25 +0200, Philippe Gerum wrote: > On Mon, 2010-04-19 at 18:14 +0200, Jan Kiszka wrote: > > Philippe Gerum wrote: > > > On Mon, 2010-04-19 at 17:58 +0200, Jan Kiszka wrote: > > >> Gilles Chanteperdrix wrote: > > >>> Jan Kiszka wrote: > > Gilles Chanteperdrix wrote: > > > Jan Kiszka wrote: > > >> Gilles Chanteperdrix wrote: > > >>> Jan Kiszka wrote: > > Gilles Chanteperdrix wrote: > > > Hi, > > > > > > I found some code which was referencing directly some > > > CONFIG_XENO_OPT_DEBUG_ variables with things like: > > > > > > #ifdef CONFIG_XENO_OPT_DEBUG_FOO > > > > > > This usage is incompatible with the pre-requisites of the assert.h > > > header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all > > > times. > > > While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also > > > have > > > many duplicates of construction like: > > > #ifndef CONFIG_XENO_OPT_DEBUG_FOO > > > #define CONFIG_XENO_OPT_DEBUG_FOO 0 > > > #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ > > > > > > So, a patch follows which: > > > - replace the #ifdef with some #if XENO_DEBUG(FOO) > > Should probably come as a separate patch. > > >>> Come on, the patch is simple, one patch for this is enough. > > >> One part is an obvious fix, the other a refactoring under discussion. > > >> > > > - move all the initializations to assert.h > > > > > > This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside > > > of > > > assert.h suspicious, and easy to detect. > > How many duplicates did you find? > > >>> A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS > > >> That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were > > >> misplaced. > > >> Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but > > >> tons > > >> of proper users. I don't see such an immediate need. > > >> > > >> When adding this kind of switching, it's till more handy to have > > >> things > > >> locally in your subsystem. That also makes reviewing easier when you > > >> only find changes in files that belong to a subsystem. > > > That is not the main point, the main point is that putting all these > > > defines in one files allow to detect easily direct references to the > > > symbols. > > > > > Generally, I'm more a fan of decentralized management here (e.g. > > this > > avoids needless patch conflicts in central files). > > >>> If we maintain the list in alphabetical order (which I have done), > > >>> we > > >>> reduce the likeliness for conflicts. The aim of doing this is also > > >>> that > > >>> I can check that the sources are clean with: > > >>> > > >>> find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep > > >>> CONFIG_XENO_OPT_DEBUG_ > > >>> > > >>> And that I can add this test to the automated build test. > > >>> > > >>> Note that forgetting to add a #define to the list yields an > > >>> immediate > > >>> compilation error. So, the patch makes things completely safe. > > >> What did you change to make this happen (for new users of > > >> XENO_DEBUG)? > > > Nothing. If you forget to add the define, and do not enable the debug > > > option (which everybody does most of the time), you get a compilation > > > error. > > The alternative (and decentralized) approach for fixing this consists > > of > > Kconfig magic for generating the value: > > > > 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 bi
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
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.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
On Mon, 2010-04-19 at 18:14 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Mon, 2010-04-19 at 17:58 +0200, Jan Kiszka wrote: > >> Gilles Chanteperdrix wrote: > >>> Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > > Jan Kiszka wrote: > >> Gilles Chanteperdrix wrote: > >>> Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > > Hi, > > > > I found some code which was referencing directly some > > CONFIG_XENO_OPT_DEBUG_ variables with things like: > > > > #ifdef CONFIG_XENO_OPT_DEBUG_FOO > > > > This usage is incompatible with the pre-requisites of the assert.h > > header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all > > times. > > While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have > > many duplicates of construction like: > > #ifndef CONFIG_XENO_OPT_DEBUG_FOO > > #define CONFIG_XENO_OPT_DEBUG_FOO 0 > > #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ > > > > So, a patch follows which: > > - replace the #ifdef with some #if XENO_DEBUG(FOO) > Should probably come as a separate patch. > >>> Come on, the patch is simple, one patch for this is enough. > >> One part is an obvious fix, the other a refactoring under discussion. > >> > > - move all the initializations to assert.h > > > > This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of > > assert.h suspicious, and easy to detect. > How many duplicates did you find? > >>> A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS > >> That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were > >> misplaced. > >> Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but tons > >> of proper users. I don't see such an immediate need. > >> > >> When adding this kind of switching, it's till more handy to have things > >> locally in your subsystem. That also makes reviewing easier when you > >> only find changes in files that belong to a subsystem. > > That is not the main point, the main point is that putting all these > > defines in one files allow to detect easily direct references to the > > symbols. > > > Generally, I'm more a fan of decentralized management here (e.g. this > avoids needless patch conflicts in central files). > >>> If we maintain the list in alphabetical order (which I have done), we > >>> reduce the likeliness for conflicts. The aim of doing this is also > >>> that > >>> I can check that the sources are clean with: > >>> > >>> find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep > >>> CONFIG_XENO_OPT_DEBUG_ > >>> > >>> And that I can add this test to the automated build test. > >>> > >>> Note that forgetting to add a #define to the list yields an immediate > >>> compilation error. So, the patch makes things completely safe. > >> What did you change to make this happen (for new users of XENO_DEBUG)? > > Nothing. If you forget to add the define, and do not enable the debug > > option (which everybody does most of the time), you get a compilation > > error. > The alternative (and decentralized) approach for fixing this consists of > Kconfig magic for generating the value: > > 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. Flexibility and robustness have to be combined. Explicit declaration in Kconfig is against flexibility, because this is one external thing more to take care of, for adding something as simple as a debug switch. So if decentralized is not important to you, then let's stop discussing about this, and find a centralized wa
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Philippe Gerum wrote: > On Mon, 2010-04-19 at 17:58 +0200, Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: Gilles Chanteperdrix wrote: > Hi, > > I found some code which was referencing directly some > CONFIG_XENO_OPT_DEBUG_ variables with things like: > > #ifdef CONFIG_XENO_OPT_DEBUG_FOO > > This usage is incompatible with the pre-requisites of the assert.h > header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. > While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have > many duplicates of construction like: > #ifndef CONFIG_XENO_OPT_DEBUG_FOO > #define CONFIG_XENO_OPT_DEBUG_FOO 0 > #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ > > So, a patch follows which: > - replace the #ifdef with some #if XENO_DEBUG(FOO) Should probably come as a separate patch. >>> Come on, the patch is simple, one patch for this is enough. >> One part is an obvious fix, the other a refactoring under discussion. >> > - move all the initializations to assert.h > > This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of > assert.h suspicious, and easy to detect. How many duplicates did you find? >>> A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS >> That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were misplaced. >> Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but tons >> of proper users. I don't see such an immediate need. >> >> When adding this kind of switching, it's till more handy to have things >> locally in your subsystem. That also makes reviewing easier when you >> only find changes in files that belong to a subsystem. > That is not the main point, the main point is that putting all these > defines in one files allow to detect easily direct references to the > symbols. > Generally, I'm more a fan of decentralized management here (e.g. this avoids needless patch conflicts in central files). >>> If we maintain the list in alphabetical order (which I have done), we >>> reduce the likeliness for conflicts. The aim of doing this is also that >>> I can check that the sources are clean with: >>> >>> find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep >>> CONFIG_XENO_OPT_DEBUG_ >>> >>> And that I can add this test to the automated build test. >>> >>> Note that forgetting to add a #define to the list yields an immediate >>> compilation error. So, the patch makes things completely safe. >> What did you change to make this happen (for new users of XENO_DEBUG)? > Nothing. If you forget to add the define, and do not enable the debug > option (which everybody does most of the time), you get a compilation > error. The alternative (and decentralized) approach for fixing this consists of Kconfig magic for generating the value: 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
On Mon, 2010-04-19 at 17:58 +0200, Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > > Jan Kiszka wrote: > >> Gilles Chanteperdrix wrote: > >>> Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > > Jan Kiszka wrote: > >> Gilles Chanteperdrix wrote: > >>> Hi, > >>> > >>> I found some code which was referencing directly some > >>> CONFIG_XENO_OPT_DEBUG_ variables with things like: > >>> > >>> #ifdef CONFIG_XENO_OPT_DEBUG_FOO > >>> > >>> This usage is incompatible with the pre-requisites of the assert.h > >>> header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. > >>> While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have > >>> many duplicates of construction like: > >>> #ifndef CONFIG_XENO_OPT_DEBUG_FOO > >>> #define CONFIG_XENO_OPT_DEBUG_FOO 0 > >>> #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ > >>> > >>> So, a patch follows which: > >>> - replace the #ifdef with some #if XENO_DEBUG(FOO) > >> Should probably come as a separate patch. > > Come on, the patch is simple, one patch for this is enough. > One part is an obvious fix, the other a refactoring under discussion. > > >>> - move all the initializations to assert.h > >>> > >>> This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of > >>> assert.h suspicious, and easy to detect. > >> How many duplicates did you find? > > A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS > That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were misplaced. > Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but tons > of proper users. I don't see such an immediate need. > > When adding this kind of switching, it's till more handy to have things > locally in your subsystem. That also makes reviewing easier when you > only find changes in files that belong to a subsystem. > >>> That is not the main point, the main point is that putting all these > >>> defines in one files allow to detect easily direct references to the > >>> symbols. > >>> > >> Generally, I'm more a fan of decentralized management here (e.g. this > >> avoids needless patch conflicts in central files). > > If we maintain the list in alphabetical order (which I have done), we > > reduce the likeliness for conflicts. The aim of doing this is also that > > I can check that the sources are clean with: > > > > find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep > > CONFIG_XENO_OPT_DEBUG_ > > > > And that I can add this test to the automated build test. > > > > Note that forgetting to add a #define to the list yields an immediate > > compilation error. So, the patch makes things completely safe. > What did you change to make this happen (for new users of XENO_DEBUG)? > >>> Nothing. If you forget to add the define, and do not enable the debug > >>> option (which everybody does most of the time), you get a compilation > >>> error. > >> The alternative (and decentralized) approach for fixing this consists of > >> Kconfig magic for generating the value: > >> > >> 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. > > We can do something like that. But I still find this more complicated > > than simply moving three lines to assert.h. > > It requires one more line but provides the safety the current approach > lacks - not worth it? > > > > > What is your problem exactly? Do you have some customer code which > > defines some more debug symbols? In that case there is no problem, you > > can keep the code as is. I plan to do the debug check part of the build > > test, not part of the makefiles. > > I have no such problems or concerns. I just find the centralization an > unclean workaround for the actual issue. > > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Hi, >>> >>> I found some code which was referencing directly some >>> CONFIG_XENO_OPT_DEBUG_ variables with things like: >>> >>> #ifdef CONFIG_XENO_OPT_DEBUG_FOO >>> >>> This usage is incompatible with the pre-requisites of the assert.h >>> header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. >>> While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have >>> many duplicates of construction like: >>> #ifndef CONFIG_XENO_OPT_DEBUG_FOO >>> #define CONFIG_XENO_OPT_DEBUG_FOO 0 >>> #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ >>> >>> So, a patch follows which: >>> - replace the #ifdef with some #if XENO_DEBUG(FOO) >> Should probably come as a separate patch. > Come on, the patch is simple, one patch for this is enough. One part is an obvious fix, the other a refactoring under discussion. >>> - move all the initializations to assert.h >>> >>> This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of >>> assert.h suspicious, and easy to detect. >> How many duplicates did you find? > A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were misplaced. Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but tons of proper users. I don't see such an immediate need. When adding this kind of switching, it's till more handy to have things locally in your subsystem. That also makes reviewing easier when you only find changes in files that belong to a subsystem. >>> That is not the main point, the main point is that putting all these >>> defines in one files allow to detect easily direct references to the >>> symbols. >>> >> Generally, I'm more a fan of decentralized management here (e.g. this >> avoids needless patch conflicts in central files). > If we maintain the list in alphabetical order (which I have done), we > reduce the likeliness for conflicts. The aim of doing this is also that > I can check that the sources are clean with: > > find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep > CONFIG_XENO_OPT_DEBUG_ > > And that I can add this test to the automated build test. > > Note that forgetting to add a #define to the list yields an immediate > compilation error. So, the patch makes things completely safe. What did you change to make this happen (for new users of XENO_DEBUG)? >>> Nothing. If you forget to add the define, and do not enable the debug >>> option (which everybody does most of the time), you get a compilation >>> error. >> The alternative (and decentralized) approach for fixing this consists of >> Kconfig magic for generating the value: >> >> 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. > > We can do something like that. But I still find this more complicated > than simply moving three lines to assert.h. It requires one more line but provides the safety the current approach lacks - not worth it? > > What is your problem exactly? Do you have some customer code which > defines some more debug symbols? In that case there is no problem, you > can keep the code as is. I plan to do the debug check part of the build > test, not part of the makefiles. I have no such problems or concerns. I just find the centralization an unclean workaround for the actual issue. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Hi, >> >> I found some code which was referencing directly some >> CONFIG_XENO_OPT_DEBUG_ variables with things like: >> >> #ifdef CONFIG_XENO_OPT_DEBUG_FOO >> >> This usage is incompatible with the pre-requisites of the assert.h >> header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. >> While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have >> many duplicates of construction like: >> #ifndef CONFIG_XENO_OPT_DEBUG_FOO >> #define CONFIG_XENO_OPT_DEBUG_FOO 0 >> #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ >> >> So, a patch follows which: >> - replace the #ifdef with some #if XENO_DEBUG(FOO) > Should probably come as a separate patch. Come on, the patch is simple, one patch for this is enough. >>> One part is an obvious fix, the other a refactoring under discussion. >>> >> - move all the initializations to assert.h >> >> This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of >> assert.h suspicious, and easy to detect. > How many duplicates did you find? A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS >>> That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were misplaced. >>> Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but tons >>> of proper users. I don't see such an immediate need. >>> >>> When adding this kind of switching, it's till more handy to have things >>> locally in your subsystem. That also makes reviewing easier when you >>> only find changes in files that belong to a subsystem. >> That is not the main point, the main point is that putting all these >> defines in one files allow to detect easily direct references to the >> symbols. >> > Generally, I'm more a fan of decentralized management here (e.g. this > avoids needless patch conflicts in central files). If we maintain the list in alphabetical order (which I have done), we reduce the likeliness for conflicts. The aim of doing this is also that I can check that the sources are clean with: find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep CONFIG_XENO_OPT_DEBUG_ And that I can add this test to the automated build test. Note that forgetting to add a #define to the list yields an immediate compilation error. So, the patch makes things completely safe. >>> What did you change to make this happen (for new users of XENO_DEBUG)? >> Nothing. If you forget to add the define, and do not enable the debug >> option (which everybody does most of the time), you get a compilation >> error. > > The alternative (and decentralized) approach for fixing this consists of > Kconfig magic for generating the value: > > 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. We can do something like that. But I still find this more complicated than simply moving three lines to assert.h. What is your problem exactly? Do you have some customer code which defines some more debug symbols? In that case there is no problem, you can keep the code as is. I plan to do the debug check part of the build test, not part of the makefiles. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: Gilles Chanteperdrix wrote: > Hi, > > I found some code which was referencing directly some > CONFIG_XENO_OPT_DEBUG_ variables with things like: > > #ifdef CONFIG_XENO_OPT_DEBUG_FOO > > This usage is incompatible with the pre-requisites of the assert.h > header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. > While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have > many duplicates of construction like: > #ifndef CONFIG_XENO_OPT_DEBUG_FOO > #define CONFIG_XENO_OPT_DEBUG_FOO 0 > #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ > > So, a patch follows which: > - replace the #ifdef with some #if XENO_DEBUG(FOO) Should probably come as a separate patch. >>> Come on, the patch is simple, one patch for this is enough. >> One part is an obvious fix, the other a refactoring under discussion. >> > - move all the initializations to assert.h > > This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of > assert.h suspicious, and easy to detect. How many duplicates did you find? >>> A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS >> That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were misplaced. >> Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but tons >> of proper users. I don't see such an immediate need. >> >> When adding this kind of switching, it's till more handy to have things >> locally in your subsystem. That also makes reviewing easier when you >> only find changes in files that belong to a subsystem. > > That is not the main point, the main point is that putting all these > defines in one files allow to detect easily direct references to the > symbols. > Generally, I'm more a fan of decentralized management here (e.g. this avoids needless patch conflicts in central files). >>> If we maintain the list in alphabetical order (which I have done), we >>> reduce the likeliness for conflicts. The aim of doing this is also that >>> I can check that the sources are clean with: >>> >>> find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep >>> CONFIG_XENO_OPT_DEBUG_ >>> >>> And that I can add this test to the automated build test. >>> >>> Note that forgetting to add a #define to the list yields an immediate >>> compilation error. So, the patch makes things completely safe. >> What did you change to make this happen (for new users of XENO_DEBUG)? > > Nothing. If you forget to add the define, and do not enable the debug > option (which everybody does most of the time), you get a compilation > error. The alternative (and decentralized) approach for fixing this consists of Kconfig magic for generating the value: 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote: > Hi, > > I found some code which was referencing directly some > CONFIG_XENO_OPT_DEBUG_ variables with things like: > > #ifdef CONFIG_XENO_OPT_DEBUG_FOO > > This usage is incompatible with the pre-requisites of the assert.h > header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. > While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have > many duplicates of construction like: > #ifndef CONFIG_XENO_OPT_DEBUG_FOO > #define CONFIG_XENO_OPT_DEBUG_FOO 0 > #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ > > So, a patch follows which: > - replace the #ifdef with some #if XENO_DEBUG(FOO) Should probably come as a separate patch. > - move all the initializations to assert.h > > This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of > assert.h suspicious, and easy to detect. How many duplicates did you find? Generally, I'm more a fan of decentralized management here (e.g. this avoids needless patch conflicts in central files). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: Hi, I found some code which was referencing directly some CONFIG_XENO_OPT_DEBUG_ variables with things like: #ifdef CONFIG_XENO_OPT_DEBUG_FOO This usage is incompatible with the pre-requisites of the assert.h header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have many duplicates of construction like: #ifndef CONFIG_XENO_OPT_DEBUG_FOO #define CONFIG_XENO_OPT_DEBUG_FOO 0 #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ So, a patch follows which: - replace the #ifdef with some #if XENO_DEBUG(FOO) >>> Should probably come as a separate patch. >> Come on, the patch is simple, one patch for this is enough. > > One part is an obvious fix, the other a refactoring under discussion. > - move all the initializations to assert.h This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of assert.h suspicious, and easy to detect. >>> How many duplicates did you find? >> A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS > > That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were misplaced. > Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but tons > of proper users. I don't see such an immediate need. > > When adding this kind of switching, it's till more handy to have things > locally in your subsystem. That also makes reviewing easier when you > only find changes in files that belong to a subsystem. That is not the main point, the main point is that putting all these defines in one files allow to detect easily direct references to the symbols. > >>> Generally, I'm more a fan of decentralized management here (e.g. this >>> avoids needless patch conflicts in central files). >> If we maintain the list in alphabetical order (which I have done), we >> reduce the likeliness for conflicts. The aim of doing this is also that >> I can check that the sources are clean with: >> >> find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep >> CONFIG_XENO_OPT_DEBUG_ >> >> And that I can add this test to the automated build test. >> >> Note that forgetting to add a #define to the list yields an immediate >> compilation error. So, the patch makes things completely safe. > > What did you change to make this happen (for new users of XENO_DEBUG)? Nothing. If you forget to add the define, and do not enable the debug option (which everybody does most of the time), you get a compilation error. What I changed, however, is that the above find | grep allows immediately to detect direct users of the symbols. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
On Mon, 2010-04-19 at 15:58 +0200, Gilles Chanteperdrix wrote: > Hi, > > I found some code which was referencing directly some > CONFIG_XENO_OPT_DEBUG_ variables with things like: > > #ifdef CONFIG_XENO_OPT_DEBUG_FOO > > This usage is incompatible with the pre-requisites of the assert.h > header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. > While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have > many duplicates of construction like: > #ifndef CONFIG_XENO_OPT_DEBUG_FOO > #define CONFIG_XENO_OPT_DEBUG_FOO 0 > #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ > > So, a patch follows which: > - replace the #ifdef with some #if XENO_DEBUG(FOO) > - move all the initializations to assert.h > Yes, that makes a lot of sense. Declaring DEBUG options locally was a sloppy fix for this annoying issue I used a lot myself. This has to be centralized somewhere. > This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of > assert.h suspicious, and easy to detect. > > Thanks in advance for any comments. > Regards. > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Hi, >>> >>> I found some code which was referencing directly some >>> CONFIG_XENO_OPT_DEBUG_ variables with things like: >>> >>> #ifdef CONFIG_XENO_OPT_DEBUG_FOO >>> >>> This usage is incompatible with the pre-requisites of the assert.h >>> header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. >>> While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have >>> many duplicates of construction like: >>> #ifndef CONFIG_XENO_OPT_DEBUG_FOO >>> #define CONFIG_XENO_OPT_DEBUG_FOO 0 >>> #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ >>> >>> So, a patch follows which: >>> - replace the #ifdef with some #if XENO_DEBUG(FOO) >> Should probably come as a separate patch. > > Come on, the patch is simple, one patch for this is enough. One part is an obvious fix, the other a refactoring under discussion. > >>> - move all the initializations to assert.h >>> >>> This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of >>> assert.h suspicious, and easy to detect. >> How many duplicates did you find? > > A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS That's because the CONFIG_XENO_OPT_DEBUG_NUCLEUS defines were misplaced. Besides that we had one CONFIG_XENO_OPT_DEBUG_QUEUE duplicate, but tons of proper users. I don't see such an immediate need. When adding this kind of switching, it's till more handy to have things locally in your subsystem. That also makes reviewing easier when you only find changes in files that belong to a subsystem. > >> Generally, I'm more a fan of decentralized management here (e.g. this >> avoids needless patch conflicts in central files). > > If we maintain the list in alphabetical order (which I have done), we > reduce the likeliness for conflicts. The aim of doing this is also that > I can check that the sources are clean with: > > find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep > CONFIG_XENO_OPT_DEBUG_ > > And that I can add this test to the automated build test. > > Note that forgetting to add a #define to the list yields an immediate > compilation error. So, the patch makes things completely safe. What did you change to make this happen (for new users of XENO_DEBUG)? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Hi, >> >> I found some code which was referencing directly some >> CONFIG_XENO_OPT_DEBUG_ variables with things like: >> >> #ifdef CONFIG_XENO_OPT_DEBUG_FOO >> >> This usage is incompatible with the pre-requisites of the assert.h >> header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. >> While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have >> many duplicates of construction like: >> #ifndef CONFIG_XENO_OPT_DEBUG_FOO >> #define CONFIG_XENO_OPT_DEBUG_FOO 0 >> #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ >> >> So, a patch follows which: >> - replace the #ifdef with some #if XENO_DEBUG(FOO) > > Should probably come as a separate patch. Come on, the patch is simple, one patch for this is enough. > >> - move all the initializations to assert.h >> >> This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of >> assert.h suspicious, and easy to detect. > > How many duplicates did you find? A lot, especially for CONFIG_XENO_OPT_DEBUG_NUCLEUS > > Generally, I'm more a fan of decentralized management here (e.g. this > avoids needless patch conflicts in central files). If we maintain the list in alphabetical order (which I have done), we reduce the likeliness for conflicts. The aim of doing this is also that I can check that the sources are clean with: find xenomai-2.5 ! -name 'assert.h' -name '*.[ch]' | xargs grep CONFIG_XENO_OPT_DEBUG_ And that I can add this test to the automated build test. Note that forgetting to add a #define to the list yields an immediate compilation error. So, the patch makes things completely safe. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Gilles Chanteperdrix wrote:
> (...)
> So, a patch follows which:
Sorry, here is a patch without the whitespace changes.
diff --git a/include/asm-generic/system.h b/include/asm-generic/system.h
index a2c8fb9..6a255c0 100644
--- a/include/asm-generic/system.h
+++ b/include/asm-generic/system.h
@@ -44,10 +44,6 @@
/* debug support */
#include
-#ifndef CONFIG_XENO_OPT_DEBUG_XNLOCK
-#define CONFIG_XENO_OPT_DEBUG_XNLOCK 0
-#endif
-
#ifdef __cplusplus
extern "C" {
#endif
diff --git a/include/native/types.h b/include/native/types.h
index 0dd721f..daeedff 100644
--- a/include/native/types.h
+++ b/include/native/types.h
@@ -32,10 +32,6 @@
#if defined(__KERNEL__) || defined(__XENO_SIM__)
-#ifndef CONFIG_XENO_OPT_DEBUG_NATIVE
-#define CONFIG_XENO_OPT_DEBUG_NATIVE 0
-#endif
-
typedef xnticks_t RTIME;
typedef xnsticks_t SRTIME;
diff --git a/include/nucleus/assert.h b/include/nucleus/assert.h
index 9cb88af..62bc329 100644
--- a/include/nucleus/assert.h
+++ b/include/nucleus/assert.h
@@ -38,4 +38,44 @@
xnpod_fatal("bug at %s:%d (%s)", __FILE__, __LINE__, (#cond)); \
} while(0)
+#ifndef CONFIG_XENO_OPT_DEBUG_NATIVE
+#define CONFIG_XENO_OPT_DEBUG_NATIVE 0
+#endif /* CONFIG_XENO_OPT_DEBUG_NATIVE */
+#ifndef CONFIG_XENO_OPT_DEBUG_NUCLEUS
+#define CONFIG_XENO_OPT_DEBUG_NUCLEUS 0
+#endif /* CONFIG_XENO_OPT_DEBUG_NUCLEUS */
+#ifndef CONFIG_XENO_OPT_DEBUG_POSIX
+#define CONFIG_XENO_OPT_DEBUG_POSIX 0
+#endif /* CONFIG_XENO_OPT_DEBUG_POSIX */
+#ifndef CONFIG_XENO_OPT_DEBUG_PSOS
+#define CONFIG_XENO_OPT_DEBUG_PSOS 0
+#endif /* CONFIG_XENO_OPT_DEBUG_PSOS */
+#ifndef CONFIG_XENO_OPT_DEBUG_QUEUES
+#define CONFIG_XENO_OPT_DEBUG_QUEUES 0
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES */
+#ifndef CONFIG_XENO_OPT_DEBUG_REGISTRY
+#define CONFIG_XENO_OPT_DEBUG_REGISTRY 0
+#endif /* CONFIG_XENO_OPT_DEBUG_REGISTRY */
+#ifndef CONFIG_XENO_OPT_DEBUG_RTDM
+#define CONFIG_XENO_OPT_DEBUG_RTDM 0
+#endif /* CONFIG_XENO_OPT_DEBUG_RTDM */
+#ifndef CONFIG_XENO_OPT_DEBUG_RTDM_APPL
+#define CONFIG_XENO_OPT_DEBUG_RTDM_APPL0
+#endif /* CONFIG_XENO_OPT_DEBUG_RTDM_APPL */
+#ifndef CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX
+#define CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX 0
+#endif /* CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX */
+#ifndef CONFIG_XENO_OPT_DEBUG_TIMERS
+#define CONFIG_XENO_OPT_DEBUG_TIMERS 0
+#endif /* CONFIG_XENO_OPT_DEBUG_TIMERS */
+#ifndef CONFIG_XENO_OPT_DEBUG_UITRON
+#define CONFIG_XENO_OPT_DEBUG_UITRON 0
+#endif /* CONFIG_XENO_OPT_DEBUG_UITRON */
+#ifndef CONFIG_XENO_OPT_DEBUG_VXWORKS
+#define CONFIG_XENO_OPT_DEBUG_VXWORKS 0
+#endif /* CONFIG_XENO_OPT_DEBUG_VXWORKS */
+#ifndef CONFIG_XENO_OPT_DEBUG_XNLOCK
+#define CONFIG_XENO_OPT_DEBUG_XNLOCK 0
+#endif /* CONFIG_XENO_OPT_DEBUG_XNLOCK */
+
#endif /* !_XENO_NUCLEUS_ASSERT_H */
diff --git a/include/nucleus/bheap.h b/include/nucleus/bheap.h
index 8b7798e..58ea93f 100644
--- a/include/nucleus/bheap.h
+++ b/include/nucleus/bheap.h
@@ -25,10 +25,6 @@
/* debug support */
#include
-#ifndef CONFIG_XENO_OPT_DEBUG_QUEUES
-#define CONFIG_XENO_OPT_DEBUG_QUEUES 0
-#endif
-
/* Priority queue implementation, using a binary heap. */
typedef unsigned long long bheap_key_t;
diff --git a/include/nucleus/heap.h b/include/nucleus/heap.h
index 77fefa6..fecdb79 100644
--- a/include/nucleus/heap.h
+++ b/include/nucleus/heap.h
@@ -46,10 +46,6 @@
#if defined(__KERNEL__) || defined(__XENO_SIM__)
-#ifndef CONFIG_XENO_OPT_DEBUG_NUCLEUS
-#define CONFIG_XENO_OPT_DEBUG_NUCLEUS 0
-#endif
-
#define XNHEAP_PAGE_SIZE 512 /* A reasonable value for the xnheap page
size */
#define XNHEAP_PAGE_MASK (~(XNHEAP_PAGE_SIZE-1))
#define XNHEAP_PAGE_ALIGN(addr)
(((addr)+XNHEAP_PAGE_SIZE-1)&XNHEAP_PAGE_MASK)
diff --git a/include/nucleus/pod.h b/include/nucleus/pod.h
index e652a1e..8831fb5 100644
--- a/include/nucleus/pod.h
+++ b/include/nucleus/pod.h
@@ -276,14 +276,14 @@ static inline void xnpod_schedule(void)
* context is active, or if we are caught in the middle of a
* unlocked context switch.
*/
-#ifdef CONFIG_XENO_OPT_DEBUG_NUCLEUS
+#if XENO_DEBUG(NUCLEUS)
if (testbits(sched->status, XNKCOUT|XNINIRQ|XNSWLOCK))
return;
-#else /* !CONFIG_XENO_OPT_DEBUG_NUCLEUS */
+#else /* !XENO_DEBUG(NUCLEUS) */
if (testbits(sched->status,
XNKCOUT|XNINIRQ|XNSWLOCK|XNRESCHED) != XNRESCHED)
return;
-#endif /* !CONFIG_XENO_OPT_DEBUG_NUCLEUS */
+#endif /* !XENO_DEBUG(NUCLEUS) */
__xnpod_schedule(sched);
}
diff --git a/include/nucleus/queue.h b/include/nucleus/queue.h
index e243f2f..15ec537 100644
--- a/include/nucleus/queue.h
+++ b/include/nucleus/queue.h
@@ -24,10 +24,6 @@
#include
#include
-#ifndef CONFIG_XENO_OPT_DEBUG_QUEUES
-#define CONFIG_XENO_OPT_DEBUG_QUEUES 0
-#endif
-
/* Basic element holder */
typedef struct xnholder {
diff --git a/include/nucleus/sched-sporadic.h
b/include/nucleus/sched-sporadic.h
index ecebc55..dfeec76 100644
--- a/include/nucleus/sched-sporadic.h
+++ b/include/nucleus/sched-s
[Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Hi, I found some code which was referencing directly some CONFIG_XENO_OPT_DEBUG_ variables with things like: #ifdef CONFIG_XENO_OPT_DEBUG_FOO This usage is incompatible with the pre-requisites of the assert.h header that CONFIG_XENO_OPT_DEBUG_FOO should be defined at all times. While grepping for CONFIG_XENO_OPT_DEBUG_, I found that we also have many duplicates of construction like: #ifndef CONFIG_XENO_OPT_DEBUG_FOO #define CONFIG_XENO_OPT_DEBUG_FOO 0 #endif /* CONFIG_XENO_OPT_DEBUG_FOO */ So, a patch follows which: - replace the #ifdef with some #if XENO_DEBUG(FOO) - move all the initializations to assert.h This will make any reference to CONFIG_XENO_OPT_DEBUG_FOO outside of assert.h suspicious, and easy to detect. Thanks in advance for any comments. Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
