[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080524143950.GG6749@1wt.eu>
Date: Sat, 24 May 2008 16:39:50 +0200
From: Willy Tarreau <w@....eu>
To: Jeremy Fitzhardinge <jeremy@...p.org>
Cc: Sam Ravnborg <sam@...nborg.org>, "H. Peter Anvin" <hpa@...or.com>,
Steve French <smfrench@...il.com>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: kernel coding style for if ... else which cross #ifdef
On Sat, May 24, 2008 at 03:35:58PM +0100, Jeremy Fitzhardinge wrote:
> Sam Ravnborg wrote:
> >I assume you wanted to say:
> >
> >> #undef CONFIG_FOO
> >> #define CFG_FOO 1
> >> #define CONFIG_FOO_MODULE
> >> #define CFG_FOO_MODULE 1
> >>
> >Because then the CONFIG_* is not changed
> >and we do not want to change that.
> >
>
> Yeah, I didn't intend to change the meaning of CONFIG_FOO.
>
> >I'm not fully convinced about:
> >
> >> #define CFG_FOO 1
> >>
> >But on the other hand it is only in odd
> >cases we distingush between built-in and module.
> >So it makes most sense.
> >
>
> I think CONFIG_ and CFG_ should be exact parallels, so if CONFIG_FOO is
> undefined, CFG_FOO should be 0.
>
> >>Not sure what CFG_* should be for string/numeric options. Probably "1"
> >>if the value is defined, "0" if not, with CONFIG_* being the actual
> >>value (so a CONFIG_ value of 0 is distinguishable from not defined).
> >>
> >For non-boolean/tristate values we simply skip CFG_ values - thats
> >the most simple approach.
>
> I suppose, but it might be useful to know whether a constant is present:
>
> if (CFG_THINGY_LIMIT && x > CONFIG_THINGY_LIMIT) {...}
>
> (which fails if CONFIG_THINGY_LIMIT is undefined, so I guess it still
> doesn't work very well).
You still have the possibility to use the "-0" trick :
if (CFG_THINGY_LIMIT && x > (CONFIG_THINGY_LIMIT-0)) {...}
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists