All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Steve French <smfrench@gmail.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: kernel coding style for if ... else which cross #ifdef
Date: Sat, 24 May 2008 15:35:58 +0100	[thread overview]
Message-ID: <483827CE.9080200@goop.org> (raw)
In-Reply-To: <20080524112704.GA7292@uranus.ravnborg.org>

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

    J

  reply	other threads:[~2008-05-24 14:36 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-23 19:11 kernel coding style for if ... else which cross #ifdef Steve French
2008-05-23 20:42 ` Willy Tarreau
2008-05-23 20:49   ` Adrian Bunk
2008-05-23 21:05     ` Willy Tarreau
2008-05-23 23:03 ` H. Peter Anvin
2008-05-24  5:43   ` Sam Ravnborg
2008-05-24  5:42     ` H. Peter Anvin
2008-05-24  6:42       ` Sam Ravnborg
2008-05-24 10:06         ` Jeremy Fitzhardinge
2008-05-24 10:49           ` Adrian Bunk
2008-05-24 11:27           ` Sam Ravnborg
2008-05-24 14:35             ` Jeremy Fitzhardinge [this message]
2008-05-24 14:39               ` Willy Tarreau
2008-05-24 14:41                 ` Jeremy Fitzhardinge
2008-05-24 14:46                   ` Willy Tarreau
2008-05-24 15:36               ` Sam Ravnborg
2008-05-24 15:45                 ` Jeremy Fitzhardinge
2008-05-24 15:57                   ` Vegard Nossum
2008-05-24 16:02                     ` Jeremy Fitzhardinge
2008-05-24 16:40                       ` Tom Spink
2008-05-24 16:42                         ` Tom Spink
2008-05-24 20:38                         ` Jeremy Fitzhardinge
2008-05-24 20:43                           ` H. Peter Anvin
2008-05-24 20:51                             ` Jeremy Fitzhardinge
2008-05-24 20:54                               ` H. Peter Anvin
2008-05-24 21:15                                 ` Jeremy Fitzhardinge
2008-05-25 23:57                                   ` Adrian Bunk
2008-05-26  0:27                                     ` H. Peter Anvin
2008-05-24 18:12                     ` H. Peter Anvin
2008-05-24 18:12                   ` H. Peter Anvin
2008-05-24 18:51                   ` Sam Ravnborg
2008-05-24 18:08         ` H. Peter Anvin

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=483827CE.9080200@goop.org \
    --to=jeremy@goop.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=smfrench@gmail.com \
    /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.