Re: [Xenomai-core] [PATCH] separate queue debugging switch

2006-02-16 Thread Philippe Gerum 

Jan Kiszka wrote:

Philippe Gerum wrote:


Jan Kiszka wrote:


Philippe Gerum wrote:



Jan Kiszka wrote:



Philippe Gerum wrote:




Jan Kiszka wrote:




Hi,

while XENO_OPT_DEBUG is generally a useful switch for tracing
potential
issues in the core and the skins, it also introduces high
latencies via
the queue debugging feature (due to checks iterating over whole
queues).

This patch introduces separate control over queue debugging so
that you
can have debug checks without too dramatic slowdowns.



Maybe it's time to introduce debug levels, so that we could reuse them
in order to
add more (selectable) debug instrumentation; queue debugging could
then
be given a
certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for
this one...), instead of going for a specific conditional each time we
introduce new checks?




Hmm, this means someone have to define what should be printed at which
level - tend to be hard decisions... Often it is at least as much
useful
to have debug groups so that specific parts can be excluded from
debugging. I'm pro such groups (one would be those queues e.g.) but
contra too many levels (2, at most 3).



Ack, selection by increasingly verbose/high-overhead groups is what I
have in mind.




At this chance, I would also suggest to introduce some ASSERT macro
(per
group, per level). That could be used to instrument the core with
runtime checks. But it could also be quickly removed at compilation
time, reducing the code size (e.g. checks at the nucleus layer against
buggy skins or at RTDM layer against rough drivers).



I'm not opposed to that, if we keep the noise / signal ratio of those
assertions at the reasonable low-level throughout the code, and don't
use this to enforce silly parametrical checks.




Then let's discuss how to implement and control this. Say we have some
macros for marking code as depends on debug group X:

#if XENO_DEBUG_GROUP(group)
code;
#endif /* XENO_DEBUG_GROUP(group) */

XENO_IF_DEBUG_GROUP(group, code);

(or do you prefere XNPOD_xxx?)



This debug code may span feature/component boundaries, so XENO_ is better.



Additionally, we could introduce that assertion macro:

XENO_ASSERT(group, expression, failure_code);

But how to control the groups now? Via Kconfig bool options?


Yes, I think so. From some specialized Debug menu in the generic
portion. We would need this to keep the (unused) debug code out of
production systems.

And what


groups to define? Per subsytem? Or per disturbance level (latency
regression)? If we control the group selection via Kconfig, we could
define pseudo bool options like All debug groups or Low-intrusive
debug groups that select the fitting concrete groups.



We won't be able to anticipate on each and every debug spots we might
need in the future, and in any case, debug triggers may well span
multiple sub-systems. I'd go for defining levels depending on the
throroughness/complexity of their checks.




To keep it simple:

XNDBG_LIGHT /* simple checks with low constant overhead */
XNDBG_HEAVY /* complex checks with high or unknown overhead */

Those two could become #defines and would have to be provide as first
argument to our debug macros.

Or we directly merge the attribute into the macro name:

XENO_DEBUG_LIGHT, XENO_IF_DEBUG_LIGHT(), XENO_ASSERT_LIGHT()
XENO_DEBUG_HEAVY, XENO_IF_DEBUG_HEAVY(), XENO_ASSERT_HEAVY()



There's no need to limit the number of debug levels, since defining what goes 
into
each of them is a matter of developer's appreciation, wrt induced overhead, and/or 
debug thoroughness. IOW, let's not impose any policy here. To keep things really 
simple, we'd also need to decouple the assertion mechanism from the debug 
thoroughness, E.g.


#if XENO_DEBUG_LEVEL  0
#define XENO_ASSERT(cond,action,fmt,args...)  do { \
if (unlikely((cond) != 0)) \
(action)(fmt , ##args); \
} while(0)
#else  /* DEBUG OFF */
#define XENO_ASSERT(cond,action,fmt,args...) do { } while(0)
#endif /* DEBUG ON */

#define XENO_BUGON(cond)  \
XENO_ASSERT(cond,xnpod_fatal,assertion failed at %s:%d,__FILE__,__LINE__)

This way, we could reserve level #1 (and above by extension) to activate all 
assertions; if people need to even control the thoroughness of assertions, they 
could just resort to implementing the assertion code in a separate debug function 
testing for particular debug levels, then calling this routine as XENO_BUGON's 
cond argument. Keeping level #0 free from assertions would be nice for 
production systems. E.g.


#if XENO_DEBUG_LEVEL  2
check_all_nucleus_queues();
#endif
...
XENO_BUGON(I_am_so_sorry);

and so on.

Setting a value for XENO_DEBUG_LEVEL would be trivial using Kconfig. Dynamic 
setting of the debug level through /proc could be obtained by forcing 
XENO_DEBUG_LEVEL to MAX_INT (i.e. when dynamic debug levels are selected from 
Kconfig), and testing some addition global variable within the debug code to 
filter out unwanted checks.





Alternatively, we could make the

Re: [Xenomai-core] [PATCH] separate queue debugging switch

2006-02-16 Thread Philippe Gerum 

Jan Kiszka wrote:

Philippe Gerum wrote:


Jan Kiszka wrote:


Philippe Gerum wrote:



Jan Kiszka wrote:



Philippe Gerum wrote:




Jan Kiszka wrote:




Hi,

while XENO_OPT_DEBUG is generally a useful switch for tracing
potential
issues in the core and the skins, it also introduces high
latencies via
the queue debugging feature (due to checks iterating over whole
queues).

This patch introduces separate control over queue debugging so
that you
can have debug checks without too dramatic slowdowns.



Maybe it's time to introduce debug levels, so that we could reuse them
in order to
add more (selectable) debug instrumentation; queue debugging could
then
be given a
certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for
this one...), instead of going for a specific conditional each time we
introduce new checks?




Hmm, this means someone have to define what should be printed at which
level - tend to be hard decisions... Often it is at least as much
useful
to have debug groups so that specific parts can be excluded from
debugging. I'm pro such groups (one would be those queues e.g.) but
contra too many levels (2, at most 3).



Ack, selection by increasingly verbose/high-overhead groups is what I
have in mind.




At this chance, I would also suggest to introduce some ASSERT macro
(per
group, per level). That could be used to instrument the core with
runtime checks. But it could also be quickly removed at compilation
time, reducing the code size (e.g. checks at the nucleus layer against
buggy skins or at RTDM layer against rough drivers).



I'm not opposed to that, if we keep the noise / signal ratio of those
assertions at the reasonable low-level throughout the code, and don't
use this to enforce silly parametrical checks.




Then let's discuss how to implement and control this. Say we have some
macros for marking code as depends on debug group X:

#if XENO_DEBUG_GROUP(group)
code;
#endif /* XENO_DEBUG_GROUP(group) */

XENO_IF_DEBUG_GROUP(group, code);

(or do you prefere XNPOD_xxx?)



This debug code may span feature/component boundaries, so XENO_ is better.



Additionally, we could introduce that assertion macro:

XENO_ASSERT(group, expression, failure_code);

But how to control the groups now? Via Kconfig bool options?


Yes, I think so. From some specialized Debug menu in the generic
portion. We would need this to keep the (unused) debug code out of
production systems.

And what


groups to define? Per subsytem? Or per disturbance level (latency
regression)? If we control the group selection via Kconfig, we could
define pseudo bool options like All debug groups or Low-intrusive
debug groups that select the fitting concrete groups.



We won't be able to anticipate on each and every debug spots we might
need in the future, and in any case, debug triggers may well span
multiple sub-systems. I'd go for defining levels depending on the
throroughness/complexity of their checks.




To keep it simple:

XNDBG_LIGHT /* simple checks with low constant overhead */
XNDBG_HEAVY /* complex checks with high or unknown overhead */

Those two could become #defines and would have to be provide as first
argument to our debug macros.

Or we directly merge the attribute into the macro name:

XENO_DEBUG_LIGHT, XENO_IF_DEBUG_LIGHT(), XENO_ASSERT_LIGHT()
XENO_DEBUG_HEAVY, XENO_IF_DEBUG_HEAVY(), XENO_ASSERT_HEAVY()



There's no need to limit the number of debug levels, since defining what goes 
into
each of them is a matter of developer's appreciation, wrt induced overhead, and/or 
debug thoroughness. IOW, let's not impose any policy here. To keep things really 
simple, we'd also need to decouple the assertion mechanism from the debug 
thoroughness, E.g.


#if XENO_DEBUG_LEVEL  0
#define XENO_ASSERT(cond,action,fmt,args...)  do { \
if (unlikely((cond) != 0)) \
(action)(fmt , ##args); \
} while(0)
#else  /* DEBUG OFF */
#define XENO_ASSERT(cond,action,fmt,args...) do { } while(0)
#endif /* DEBUG ON */

#define XENO_BUGON(cond)  \
XENO_ASSERT(cond,xnpod_fatal,assertion failed at %s:%d,__FILE__,__LINE__)

This way, we could reserve level #1 (and above by extension) to activate all 
assertions; if people need to even control the thoroughness of assertions, they 
could just resort to implementing the assertion code in a separate debug function 
testing for particular debug levels, then calling this routine as XENO_BUGON's 
cond argument. Keeping level #0 free from assertions would be nice for 
production systems. E.g.


#if XENO_DEBUG_LEVEL  2
check_all_nucleus_queues();
#endif
...
XENO_BUGON(I_am_so_sorry);

and so on.

Setting a value for XENO_DEBUG_LEVEL would be trivial using Kconfig. Dynamic 
setting of the debug level through /proc could be obtained by forcing 
XENO_DEBUG_LEVEL to MAX_INT (i.e. when dynamic debug levels are selected from 
Kconfig), and testing some addition global variable within the debug code to 
filter out unwanted checks.





Alternatively, we could make the

Re: [Xenomai-core] [PATCH] separate queue debugging switch

2006-02-15 Thread Philippe Gerum 

Jan Kiszka wrote:

Philippe Gerum wrote:


Jan Kiszka wrote:


Philippe Gerum wrote:



Jan Kiszka wrote:



Hi,

while XENO_OPT_DEBUG is generally a useful switch for tracing potential
issues in the core and the skins, it also introduces high latencies via
the queue debugging feature (due to checks iterating over whole
queues).

This patch introduces separate control over queue debugging so that you
can have debug checks without too dramatic slowdowns.



Maybe it's time to introduce debug levels, so that we could reuse them
in order to
add more (selectable) debug instrumentation; queue debugging could then
be given a
certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for
this one...), instead of going for a specific conditional each time we
introduce new checks?




Hmm, this means someone have to define what should be printed at which
level - tend to be hard decisions... Often it is at least as much useful
to have debug groups so that specific parts can be excluded from
debugging. I'm pro such groups (one would be those queues e.g.) but
contra too many levels (2, at most 3).



Ack, selection by increasingly verbose/high-overhead groups is what I
have in mind.



At this chance, I would also suggest to introduce some ASSERT macro (per
group, per level). That could be used to instrument the core with
runtime checks. But it could also be quickly removed at compilation
time, reducing the code size (e.g. checks at the nucleus layer against
buggy skins or at RTDM layer against rough drivers).



I'm not opposed to that, if we keep the noise / signal ratio of those
assertions at the reasonable low-level throughout the code, and don't
use this to enforce silly parametrical checks.




Then let's discuss how to implement and control this. Say we have some
macros for marking code as depends on debug group X:

#if XENO_DEBUG_GROUP(group)
code;
#endif /* XENO_DEBUG_GROUP(group) */

XENO_IF_DEBUG_GROUP(group, code);

(or do you prefere XNPOD_xxx?)



This debug code may span feature/component boundaries, so XENO_ is better.


Additionally, we could introduce that assertion macro:

XENO_ASSERT(group, expression, failure_code);

But how to control the groups now? Via Kconfig bool options?


Yes, I think so. From some specialized Debug menu in the generic portion. We would 
need this to keep the (unused) debug code out of production systems.


 And what

groups to define? Per subsytem? Or per disturbance level (latency
regression)? If we control the group selection via Kconfig, we could
define pseudo bool options like All debug groups or Low-intrusive
debug groups that select the fitting concrete groups.



We won't be able to anticipate on each and every debug spots we might need in the 
future, and in any case, debug triggers may well span multiple sub-systems. I'd go 
for defining levels depending on the throroughness/complexity of their checks.



Alternatively, we could make the group selection a runtime switch,
controlled via a global bitmask that can be modified through /proc e.g.
Only switching of CONFIG_XENO_OPT_DEBUG would then remove all debugging
code, otherwise the execution of the checks would depend on the current
bitmask content.


We could cumulate this with the static selection.



Jan




--

Philippe.

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

Re: [Xenomai-core] [PATCH] separate queue debugging switch

2006-02-15 Thread Jan Kiszka 
Philippe Gerum wrote:
 Jan Kiszka wrote:
 Philippe Gerum wrote:

 Jan Kiszka wrote:

 Philippe Gerum wrote:


 Jan Kiszka wrote:


 Hi,

 while XENO_OPT_DEBUG is generally a useful switch for tracing
 potential
 issues in the core and the skins, it also introduces high
 latencies via
 the queue debugging feature (due to checks iterating over whole
 queues).

 This patch introduces separate control over queue debugging so
 that you
 can have debug checks without too dramatic slowdowns.


 Maybe it's time to introduce debug levels, so that we could reuse them
 in order to
 add more (selectable) debug instrumentation; queue debugging could
 then
 be given a
 certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for
 this one...), instead of going for a specific conditional each time we
 introduce new checks?



 Hmm, this means someone have to define what should be printed at which
 level - tend to be hard decisions... Often it is at least as much
 useful
 to have debug groups so that specific parts can be excluded from
 debugging. I'm pro such groups (one would be those queues e.g.) but
 contra too many levels (2, at most 3).


 Ack, selection by increasingly verbose/high-overhead groups is what I
 have in mind.


 At this chance, I would also suggest to introduce some ASSERT macro
 (per
 group, per level). That could be used to instrument the core with
 runtime checks. But it could also be quickly removed at compilation
 time, reducing the code size (e.g. checks at the nucleus layer against
 buggy skins or at RTDM layer against rough drivers).


 I'm not opposed to that, if we keep the noise / signal ratio of those
 assertions at the reasonable low-level throughout the code, and don't
 use this to enforce silly parametrical checks.



 Then let's discuss how to implement and control this. Say we have some
 macros for marking code as depends on debug group X:

 #if XENO_DEBUG_GROUP(group)
 code;
 #endif /* XENO_DEBUG_GROUP(group) */

 XENO_IF_DEBUG_GROUP(group, code);

 (or do you prefere XNPOD_xxx?)

 
 This debug code may span feature/component boundaries, so XENO_ is better.
 
 Additionally, we could introduce that assertion macro:

 XENO_ASSERT(group, expression, failure_code);

 But how to control the groups now? Via Kconfig bool options?
 
 Yes, I think so. From some specialized Debug menu in the generic
 portion. We would need this to keep the (unused) debug code out of
 production systems.
 
  And what
 groups to define? Per subsytem? Or per disturbance level (latency
 regression)? If we control the group selection via Kconfig, we could
 define pseudo bool options like All debug groups or Low-intrusive
 debug groups that select the fitting concrete groups.

 
 We won't be able to anticipate on each and every debug spots we might
 need in the future, and in any case, debug triggers may well span
 multiple sub-systems. I'd go for defining levels depending on the
 throroughness/complexity of their checks.
 

To keep it simple:

XNDBG_LIGHT /* simple checks with low constant overhead */
XNDBG_HEAVY /* complex checks with high or unknown overhead */

Those two could become #defines and would have to be provide as first
argument to our debug macros.

Or we directly merge the attribute into the macro name:

XENO_DEBUG_LIGHT, XENO_IF_DEBUG_LIGHT(), XENO_ASSERT_LIGHT()
XENO_DEBUG_HEAVY, XENO_IF_DEBUG_HEAVY(), XENO_ASSERT_HEAVY()

 Alternatively, we could make the group selection a runtime switch,
 controlled via a global bitmask that can be modified through /proc e.g.
 Only switching of CONFIG_XENO_OPT_DEBUG would then remove all debugging
 code, otherwise the execution of the checks would depend on the current
 bitmask content.
 
 We could cumulate this with the static selection.
 

Then this is also a perfect add-on - for later work. :)

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] [PATCH] separate queue debugging switch

2006-02-14 Thread Jan Kiszka 
Jan Kiszka wrote:
 Hi,
 
 while XENO_OPT_DEBUG is generally a useful switch for tracing potential
 issues in the core and the skins, it also introduces high latencies via
 the queue debugging feature (due to checks iterating over whole queues).
 
 This patch introduces separate control over queue debugging so that you
 can have debug checks without too dramatic slowdowns.
 

And this revision also takes care of 2.4.

Jan
Index: ksrc/nucleus/Kconfig
===
--- ksrc/nucleus/Kconfig(revision 564)
+++ ksrc/nucleus/Kconfig(working copy)
@@ -87,6 +87,15 @@
Do not switch this option on unless you really know what you
are doing.
 
+config XENO_OPT_DEBUG_QUEUES
+   bool Queue Debugging support
+   depends on XENO_OPT_DEBUG
+   help
+   
+   This option activates debugging checks for all queueing
+   operations of the Xenomai core. It adds even more runtime
+   overhead then CONFIG_XENO_OPT_DEBUG, use with care.
+
 config XENO_OPT_WATCHDOG
bool Watchdog support
default n
Index: ksrc/nucleus/Config.in
===
--- ksrc/nucleus/Config.in  (revision 564)
+++ ksrc/nucleus/Config.in  (working copy)
@@ -18,6 +18,9 @@
bool 'Interrupt shield support' CONFIG_XENO_OPT_ISHIELD
bool 'Statistics collection' CONFIG_XENO_OPT_STATS
bool 'Debug support' CONFIG_XENO_OPT_DEBUG
+   if [ $CONFIG_XENO_OPT_DEBUG = y ]; then
+   bool 'Queue Debugging support' CONFIG_XENO_OPT_DEBUG_QUEUES
+   fi
bool 'Watchdog support' CONFIG_XENO_OPT_WATCHDOG
 
bool 'Enable periodic timer support' CONFIG_XENO_OPT_TIMING_PERIODIC
Index: include/nucleus/queue.h
===
--- include/nucleus/queue.h (revision 564)
+++ include/nucleus/queue.h (working copy)
@@ -57,27 +57,27 @@
 
 xnholder_t head;
 int elems;
-#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG)  
defined(CONFIG_SMP)
+#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG_QUEUES)  
defined(CONFIG_SMP)
 xnlock_t lock;
-#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG  CONFIG_SMP */
+#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP */
 
 } xnqueue_t;
 
-#if defined(CONFIG_XENO_OPT_DEBUG)  defined(CONFIG_SMP)
+#if defined(CONFIG_XENO_OPT_DEBUG_QUEUES)  defined(CONFIG_SMP)
 #define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0, 
XNARCH_LOCK_UNLOCKED }
-#else /* !(CONFIG_XENO_OPT_DEBUG  CONFIG_SMP) */
+#else /* !(CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP) */
 #define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0 }
-#endif /* CONFIG_XENO_OPT_DEBUG  CONFIG_SMP */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP */
 
 static inline void initq (xnqueue_t *qslot) {
 inith(qslot-head);
 qslot-elems = 0;
-#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG)  
defined(CONFIG_SMP)
+#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG_QUEUES)  
defined(CONFIG_SMP)
 xnlock_init(qslot-lock);
-#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG  CONFIG_SMP */
+#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP */
 }
 
-#ifdef CONFIG_XENO_OPT_DEBUG
+#ifdef CONFIG_XENO_OPT_DEBUG_QUEUES
 
 #if defined(__KERNEL__) || defined(__XENO_UVM__) || defined(__XENO_SIM__)
 
@@ -172,7 +172,7 @@
dth(__holder);  \
--(__qslot)-elems; })
 
-#else /* !CONFIG_XENO_OPT_DEBUG */
+#else /* !CONFIG_XENO_OPT_DEBUG_QUEUES */
 
 static inline int insertq (xnqueue_t *qslot,
xnholder_t *head,
@@ -206,7 +206,7 @@
 return --qslot-elems;
 }
 
-#endif /* CONFIG_XENO_OPT_DEBUG */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES */
 
 static inline xnholder_t *getheadq (xnqueue_t *qslot)
 {


signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] [PATCH] separate queue debugging switch

2006-02-14 Thread Philippe Gerum 

Jan Kiszka wrote:

Hi,

while XENO_OPT_DEBUG is generally a useful switch for tracing potential
issues in the core and the skins, it also introduces high latencies via
the queue debugging feature (due to checks iterating over whole queues).

This patch introduces separate control over queue debugging so that you
can have debug checks without too dramatic slowdowns.



Maybe it's time to introduce debug levels, so that we could reuse them in order 
to
add more (selectable) debug instrumentation; queue debugging could then be 
given a
certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for this 
one...), instead of going for a specific conditional each time we introduce new 
checks?



Jan




Index: ksrc/nucleus/Kconfig
===
--- ksrc/nucleus/Kconfig(revision 564)
+++ ksrc/nucleus/Kconfig(working copy)
@@ -87,6 +87,15 @@
Do not switch this option on unless you really know what you
are doing.
 
+config XENO_OPT_DEBUG_QUEUES

+   bool Queue Debugging support
+   depends on XENO_OPT_DEBUG
+   help
+   
+   This option activates debugging checks for all queueing
+   operations of the Xenomai core. It adds even more runtime
+   overhead then CONFIG_XENO_OPT_DEBUG, use with care.
+
 config XENO_OPT_WATCHDOG
bool Watchdog support
default n
Index: include/nucleus/queue.h
===
--- include/nucleus/queue.h (revision 564)
+++ include/nucleus/queue.h (working copy)
@@ -57,27 +57,27 @@
 
 xnholder_t head;

 int elems;
-#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG)  
defined(CONFIG_SMP)
+#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG_QUEUES)  
defined(CONFIG_SMP)
 xnlock_t lock;
-#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG  CONFIG_SMP */
+#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP */
 
 } xnqueue_t;
 
-#if defined(CONFIG_XENO_OPT_DEBUG)  defined(CONFIG_SMP)

+#if defined(CONFIG_XENO_OPT_DEBUG_QUEUES)  defined(CONFIG_SMP)
 #define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0, 
XNARCH_LOCK_UNLOCKED }
-#else /* !(CONFIG_XENO_OPT_DEBUG  CONFIG_SMP) */
+#else /* !(CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP) */
 #define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0 }
-#endif /* CONFIG_XENO_OPT_DEBUG  CONFIG_SMP */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP */
 
 static inline void initq (xnqueue_t *qslot) {

 inith(qslot-head);
 qslot-elems = 0;
-#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG)  
defined(CONFIG_SMP)
+#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG_QUEUES)  
defined(CONFIG_SMP)
 xnlock_init(qslot-lock);
-#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG  CONFIG_SMP */
+#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP */
 }
 
-#ifdef CONFIG_XENO_OPT_DEBUG

+#ifdef CONFIG_XENO_OPT_DEBUG_QUEUES
 
 #if defined(__KERNEL__) || defined(__XENO_UVM__) || defined(__XENO_SIM__)
 
@@ -172,7 +172,7 @@

dth(__holder);  \
--(__qslot)-elems; })
 
-#else /* !CONFIG_XENO_OPT_DEBUG */

+#else /* !CONFIG_XENO_OPT_DEBUG_QUEUES */
 
 static inline int insertq (xnqueue_t *qslot,

xnholder_t *head,
@@ -206,7 +206,7 @@
 return --qslot-elems;
 }
 
-#endif /* CONFIG_XENO_OPT_DEBUG */

+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES */
 
 static inline xnholder_t *getheadq (xnqueue_t *qslot)

 {




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



--

Philippe.


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

Re: [Xenomai-core] [PATCH] separate queue debugging switch

2006-02-14 Thread Philippe Gerum 

Jan Kiszka wrote:

Philippe Gerum wrote:


Jan Kiszka wrote:


Hi,

while XENO_OPT_DEBUG is generally a useful switch for tracing potential
issues in the core and the skins, it also introduces high latencies via
the queue debugging feature (due to checks iterating over whole queues).

This patch introduces separate control over queue debugging so that you
can have debug checks without too dramatic slowdowns.



Maybe it's time to introduce debug levels, so that we could reuse them
in order to
add more (selectable) debug instrumentation; queue debugging could then
be given a
certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for
this one...), instead of going for a specific conditional each time we
introduce new checks?




Hmm, this means someone have to define what should be printed at which
level - tend to be hard decisions... Often it is at least as much useful
to have debug groups so that specific parts can be excluded from
debugging. I'm pro such groups (one would be those queues e.g.) but
contra too many levels (2, at most 3).



Ack, selection by increasingly verbose/high-overhead groups is what I have in 
mind.


At this chance, I would also suggest to introduce some ASSERT macro (per
group, per level). That could be used to instrument the core with
runtime checks. But it could also be quickly removed at compilation
time, reducing the code size (e.g. checks at the nucleus layer against
buggy skins or at RTDM layer against rough drivers).



I'm not opposed to that, if we keep the noise / signal ratio of those assertions 
at the reasonable low-level throughout the code, and don't use this to enforce 
silly parametrical checks.



Jan




--

Philippe.

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

[Xenomai-core] [PATCH] separate queue debugging switch

2006-02-14 Thread Jan Kiszka 
Hi,

while XENO_OPT_DEBUG is generally a useful switch for tracing potential
issues in the core and the skins, it also introduces high latencies via
the queue debugging feature (due to checks iterating over whole queues).

This patch introduces separate control over queue debugging so that you
can have debug checks without too dramatic slowdowns.

Jan
Index: ksrc/nucleus/Kconfig
===
--- ksrc/nucleus/Kconfig(revision 564)
+++ ksrc/nucleus/Kconfig(working copy)
@@ -87,6 +87,15 @@
Do not switch this option on unless you really know what you
are doing.
 
+config XENO_OPT_DEBUG_QUEUES
+   bool Queue Debugging support
+   depends on XENO_OPT_DEBUG
+   help
+   
+   This option activates debugging checks for all queueing
+   operations of the Xenomai core. It adds even more runtime
+   overhead then CONFIG_XENO_OPT_DEBUG, use with care.
+
 config XENO_OPT_WATCHDOG
bool Watchdog support
default n
Index: include/nucleus/queue.h
===
--- include/nucleus/queue.h (revision 564)
+++ include/nucleus/queue.h (working copy)
@@ -57,27 +57,27 @@
 
 xnholder_t head;
 int elems;
-#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG)  
defined(CONFIG_SMP)
+#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG_QUEUES)  
defined(CONFIG_SMP)
 xnlock_t lock;
-#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG  CONFIG_SMP */
+#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP */
 
 } xnqueue_t;
 
-#if defined(CONFIG_XENO_OPT_DEBUG)  defined(CONFIG_SMP)
+#if defined(CONFIG_XENO_OPT_DEBUG_QUEUES)  defined(CONFIG_SMP)
 #define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0, 
XNARCH_LOCK_UNLOCKED }
-#else /* !(CONFIG_XENO_OPT_DEBUG  CONFIG_SMP) */
+#else /* !(CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP) */
 #define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0 }
-#endif /* CONFIG_XENO_OPT_DEBUG  CONFIG_SMP */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP */
 
 static inline void initq (xnqueue_t *qslot) {
 inith(qslot-head);
 qslot-elems = 0;
-#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG)  
defined(CONFIG_SMP)
+#if defined(__KERNEL__)  defined(CONFIG_XENO_OPT_DEBUG_QUEUES)  
defined(CONFIG_SMP)
 xnlock_init(qslot-lock);
-#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG  CONFIG_SMP */
+#endif /* __KERNEL__  CONFIG_XENO_OPT_DEBUG_QUEUES  CONFIG_SMP */
 }
 
-#ifdef CONFIG_XENO_OPT_DEBUG
+#ifdef CONFIG_XENO_OPT_DEBUG_QUEUES
 
 #if defined(__KERNEL__) || defined(__XENO_UVM__) || defined(__XENO_SIM__)
 
@@ -172,7 +172,7 @@
dth(__holder);  \
--(__qslot)-elems; })
 
-#else /* !CONFIG_XENO_OPT_DEBUG */
+#else /* !CONFIG_XENO_OPT_DEBUG_QUEUES */
 
 static inline int insertq (xnqueue_t *qslot,
xnholder_t *head,
@@ -206,7 +206,7 @@
 return --qslot-elems;
 }
 
-#endif /* CONFIG_XENO_OPT_DEBUG */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES */
 
 static inline xnholder_t *getheadq (xnqueue_t *qslot)
 {


signature.asc
Description: OpenPGP digital signature

Re: [Xenomai-core] [PATCH] separate queue debugging switch

2006-02-14 Thread Jan Kiszka 
Philippe Gerum wrote:
 Jan Kiszka wrote:
 Hi,

 while XENO_OPT_DEBUG is generally a useful switch for tracing potential
 issues in the core and the skins, it also introduces high latencies via
 the queue debugging feature (due to checks iterating over whole queues).

 This patch introduces separate control over queue debugging so that you
 can have debug checks without too dramatic slowdowns.

 
 Maybe it's time to introduce debug levels, so that we could reuse them
 in order to
 add more (selectable) debug instrumentation; queue debugging could then
 be given a
 certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for
 this one...), instead of going for a specific conditional each time we
 introduce new checks?
 

Hmm, this means someone have to define what should be printed at which
level - tend to be hard decisions... Often it is at least as much useful
to have debug groups so that specific parts can be excluded from
debugging. I'm pro such groups (one would be those queues e.g.) but
contra too many levels (2, at most 3).

At this chance, I would also suggest to introduce some ASSERT macro (per
group, per level). That could be used to instrument the core with
runtime checks. But it could also be quickly removed at compilation
time, reducing the code size (e.g. checks at the nucleus layer against
buggy skins or at RTDM layer against rough drivers).

Jan



signature.asc
Description: OpenPGP digital signature