All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Date: Mon, 19 Apr 2010 19:21:11 +0200	[thread overview]
Message-ID: <4BCC9107.1080605@domain.hid> (raw)
In-Reply-To: <4BCC8484.1020108@domain.hid>

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


  reply	other threads:[~2010-04-19 17:21 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19 13:58 [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs Gilles Chanteperdrix
2010-04-19 14:00 ` [Xenomai-core] [PATCH] debug: fix direct references to CONFIG_XENO_OPT_DEBUG_* Gilles Chanteperdrix
2010-04-19 14:05 ` [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs Gilles Chanteperdrix
2010-04-19 14:47 ` Jan Kiszka
2010-04-19 14:52   ` Gilles Chanteperdrix
2010-04-19 15:02     ` Jan Kiszka
2010-04-19 15:07       ` Gilles Chanteperdrix
2010-04-19 15:33         ` Jan Kiszka
2010-04-19 15:37           ` Gilles Chanteperdrix
2010-04-19 15:58             ` Jan Kiszka
2010-04-19 16:10               ` Philippe Gerum
2010-04-19 16:14                 ` Jan Kiszka
2010-04-19 16:25                   ` Philippe Gerum
2010-04-19 16:43                     ` Philippe Gerum
2010-04-19 17:22                       ` Jan Kiszka
2010-04-19 17:23                         ` Philippe Gerum
2010-04-19 17:27                         ` Philippe Gerum
2010-04-19 16:27                   ` Gilles Chanteperdrix
2010-04-19 17:21                     ` Jan Kiszka [this message]
2010-04-19 17:26                       ` Gilles Chanteperdrix
2010-04-19 17:43                         ` Jan Kiszka
2010-04-19 17:56                           ` Gilles Chanteperdrix
2010-04-19 18:03                           ` Gilles Chanteperdrix
2010-04-19 18:14                             ` Gilles Chanteperdrix
2010-04-19 18:18                               ` Jan Kiszka
2010-04-19 18:22                                 ` Gilles Chanteperdrix
2010-04-19 18:38                                   ` Jan Kiszka
2010-04-19 18:41                                     ` Gilles Chanteperdrix
2010-04-19 19:08                                       ` Jan Kiszka
2010-04-19 19:21                                         ` Gilles Chanteperdrix
2010-04-19 19:37                                           ` Jan Kiszka
2010-04-19 19:47                                             ` Gilles Chanteperdrix
2010-04-19 20:08                                               ` Jan Kiszka
2010-04-19 20:33                                                 ` Gilles Chanteperdrix
2010-04-19 19:55                                             ` Gilles Chanteperdrix
2010-04-20 12:48   ` Gilles Chanteperdrix
2010-04-20 14:02     ` Gilles Chanteperdrix
2010-04-19 15:06 ` Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BCC9107.1080605@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=gilles.chanteperdrix@xenomai.org \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.